RFC 6256 - Using Self-Delimiting Numeric Values in Protocols 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6256
タイトル : RFC 6256 - プロトコルで自己削減数値値を使用します
翻訳編集 : 自動生成

[要約] RFC 6256は、プロトコルで自己区切り数値を使用するためのガイドラインです。その目的は、数値の区切りを明確にすることで、プロトコルの解析と処理を容易にすることです。

Internet Research Task Force (IRTF)                              W. Eddy
Request for Comments: 6256                                   MTI Systems
Category: Informational                                        E. Davies
ISSN: 2070-1721                                         Folly Consulting
                                                                May 2011

Using Self-Delimiting Numeric Values in Protocols

プロトコルで自己削減数値値を使用します

Abstract

概要

Self-Delimiting Numeric Values (SDNVs) have recently been introduced as a field type in proposed Delay-Tolerant Networking protocols. SDNVs encode an arbitrary-length non-negative integer or arbitrary-length bitstring with minimum overhead. They are intended to provide protocol flexibility without sacrificing economy and to assist in future-proofing protocols under development. This document describes formats and algorithms for SDNV encoding and decoding, along with notes on implementation and usage. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.

自発的な数値値（SDNV）は、提案された遅延耐性ネットワークプロトコルのフィールドタイプとして最近導入されました。SDNVSは、最小オーバーヘッドで任意の長さの非陰性整数または任意の長さのビットストリングをエンコードします。彼らは、経済を犠牲にすることなくプロトコルの柔軟性を提供し、開発中の将来の防止プロトコルを支援することを目的としています。このドキュメントでは、実装と使用に関するメモとともに、SDNVエンコードとデコードのフォーマットとアルゴリズムについて説明します。このドキュメントは、遅延耐性ネットワーキング研究グループの製品であり、そのグループによってレビューされています。RFCとしての出版に対する異議は提起されませんでした。

Status of This Memo

本文書の位置付け

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。

This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Delay-Tolerant Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（IRTF）の遅延耐性ネットワーキング研究グループのコンセンサスを表しています。IRSGによって公開されたことが承認された文書は、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6256.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6256で取得できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。

Table of Contents

   1. Introduction ....................................................2
      1.1. Problems with Fixed-Value Fields ...........................3
      1.2. SDNVs for DTN Protocols ....................................4
      1.3. SDNV Usage .................................................5
   2. Definition of SDNVs .............................................6
   3. Basic Algorithms ................................................8
      3.1. Encoding Algorithm .........................................8
      3.2. Decoding Algorithm .........................................9
      3.3. Limitations of Implementations ............................10
   4. Comparison to Alternatives .....................................10
   5. Security Considerations ........................................13
   6. Acknowledgements ...............................................13
   7. Informative References .........................................14
   Appendix A. SDNV Python Source Code ...............................15

1. Introduction

1. はじめに

This document is a product of the Internet Research Task Force (IRTF) Delay-Tolerant Networking (DTN) Research Group (DTNRG). The document has received review and support within the DTNRG, as discussed in the Acknowledgements section of this document.

このドキュメントは、インターネット研究タスクフォース（IRTF）遅延耐性ネットワーキング（DTN）研究グループ（DTNRG）の製品です。このドキュメントは、このドキュメントの謝辞セクションで説明されているように、DTNRG内でレビューとサポートを受けています。

This document begins by describing the drawbacks of using fixed-width protocol fields. It then provides some background on the Self-Delimiting Numeric Values (SDNVs) proposed for use in DTN protocols, and motivates their potential applicability in other networking protocols. The DTNRG has created SDNVs to meet the challenges it attempts to solve, and it has been noted that SDNVs closely resemble certain constructs within ASN.1 and even older ITU protocols, so the problems are not new or unique to DTN. SDNVs focus strictly on numeric values or bitstrings, while other mechanisms have been developed for encoding more complex data structures, such as ASN.1 encoding rules and Haverty's Message Services Data Transmission Protocol (MSDTP) [RFC0713]. Because of this focus, SDNVs can be quickly implemented with only a small amount of code.

このドキュメントは、固定幅プロトコルフィールドを使用することの欠点を説明することから始まります。次に、DTNプロトコルで使用するために提案された自己削減数値（SDNV）の背景を提供し、他のネットワーキングプロトコルでの潜在的な適用性を動機付けます。DTNRGは、解決しようとする課題を満たすためにSDNVを作成しました。SDNVは、ASN.1およびさらに古いITUプロトコル内の特定の構成によく似ているため、問題は新しいものではなく、DTNに固有のものではありません。SDNVは数値またはビットストリングに厳密に焦点を当て、ASN.1エンコードルールやHavertyのメッセージサービスデータ送信プロトコル（MSDTP）[RFC0713]などのより複雑なデータ構造をエンコードするために他のメカニズムが開発されています。この焦点のため、SDNVは少量のコードのみで迅速に実装できます。

SDNVs are tersely defined in both the Bundle Protocol [RFC5050] and Licklider Transmission Protocol (LTP) [RFC5326] specifications, due to the flow of document production in the DTNRG. This document clarifies and further explains the motivations and engineering decisions behind SDNVs.

SDNVは、DTNRGでのドキュメント生産の流れにより、バンドルプロトコル[RFC5050]とLicklider透過プロトコル（LTP）[RFC5326]仕様の両方で熱く定義されています。この文書は、SDNVの背後にある動機と工学の決定を明確にし、さらに説明します。

1.1. Problems with Fixed-Value Fields

1.1. 固定値フィールドの問題

Protocol designers commonly face an optimization problem in determining the proper size for header fields. There is a strong desire to keep fields as small as possible, in order to reduce the protocol's overhead and also allow for fast processing. Since protocols can be used for many years (even decades) after they are designed, and networking technology has tended to change rapidly, it is not uncommon for the use, deployment, or performance of a particular protocol to be limited or infringed upon by the length of some header field being too short. Two well-known examples of this phenomenon are the TCP-advertised receive window and the IPv4 address length.

プロトコル設計者は、一般に、ヘッダーフィールドの適切なサイズを決定する際に最適化の問題に直面しています。プロトコルのオーバーヘッドを削減し、高速処理を可能にするために、フィールドをできるだけ小さく保ちたいという強い欲求があります。プロトコルは、設計後に長年（数十年）使用できるため、ネットワーキングテクノロジーは急速に変化する傾向があるため、特定のプロトコルの使用、展開、またはパフォーマンスが制限または侵害されることは珍しくありません。一部のヘッダーフィールドの長さが短すぎます。この現象の2つのよく知られている例は、TCP advertided受信ウィンドウとIPv4アドレスの長さです。

TCP segments contain an advertised receive window field that is fixed at 16 bits [RFC0793], encoding a maximum value of around 65 kilobytes. The purpose of this value is to provide flow control, by allowing a receiver to specify how many sent bytes its peer can have outstanding (unacknowledged) at any time, thus allowing the receiver to limit its buffer size. As network speeds have grown by several orders of magnitude since TCP's inception, the combination of the 65 kilobyte maximum advertised window and long round-trip times prevented TCP senders from being able to achieve the high throughput that the underlying network supported. This limitation was remedied through the use of the Window Scale option [RFC1323], which provides a multiplier for the advertised window field. However, the Window Scale multiplier is fixed for the duration of the connection, requires support from each end of a TCP connection, and limits the precision of the advertised receive window, so this is certainly a less-than-ideal solution. Because of the field width limit in the original design however, the Window Scale is necessary for TCP to reach high sending rates.

TCPセグメントには、16ビット[RFC0793]に固定された広告の受信ウィンドウフィールドが含まれており、最大値は約65キロバイトです。この値の目的は、レシーバーがピアの送信バイト数をいつでも傑出した（未貼り付けられていない）を指定できるようにすることにより、フロー制御を提供することです。TCPの開始以来、ネットワーク速度が数桁増加しているため、65キロバイトの最大広告ウィンドウと長い往復時間の組み合わせにより、TCP送信者は、基礎となるネットワークがサポートする高スループットを達成することができなくなりました。この制限は、広告されたウィンドウフィールドに乗数を提供するウィンドウスケールオプション[RFC1323]を使用して改善されました。ただし、ウィンドウスケールの乗数は接続の期間中固定されており、TCP接続の各端からのサポートが必要であり、広告された受信ウィンドウの精度を制限するため、これは確かに理想的ではないソリューションです。ただし、元の設計ではフィールド幅の制限があるため、TCPが高い送信率に達するにはウィンドウスケールが必要です。

An IPv4 address is fixed at 32 bits [RFC0791] (as a historical note, an early version of the IP header format specification in [IEN21] used variable-length addresses in multiples of 8 bits up to 120 bits). Due to the way that subnetting and assignment of address blocks was performed, the number of IPv4 addresses has been seen as a limit to the growth of the Internet [Hain05]. Two divergent paths to solve this problem have been the use of Network Address Translators (NATs) and the development of IPv6. NATs have caused a number of other issues and problems [RFC2993], leading to increased complexity and fragility, as well as forcing workarounds to be engineered for many other protocols to function within a NATed environment. The IPv6 solution's transitional work has been underway for several years, but has still only just begun to have visible impact on the global Internet.

IPv4アドレスは32ビット[RFC0791]に固定されています（履歴ノートとして、[IEN21]のIPヘッダー形式の仕様の初期バージョンは、最大120ビットの8ビットの倍数で可変長アドレスを使用しました）。アドレスブロックのサブネットと割り当ての実行方法により、IPv4アドレスの数はインターネットの成長の制限と見なされています[HAIN05]。この問題を解決するための2つの分岐パスは、ネットワークアドレス翻訳者（NAT）の使用とIPv6の開発です。NATは他の多くの問題と問題を引き起こし[RFC2993]、複雑さと脆弱性の増加につながり、他の多くのプロトコルがネート環境内で機能するように設計されることを強制しています。IPv6ソリューションの移行作業は数年前から進行中ですが、グローバルインターネットに目に見える影響を受け始めたばかりです。

Of course, in both the case of the TCP receive window and IPv4 address length, the field size chosen by the designers seemed like a good idea at the time. The fields were more than big enough for the originally perceived usage of the protocols, and yet were small enough to allow the headers to remain compact and relatively easy and efficient to parse on machines of the time. The fixed sizes that were defined represented a trade-off between the scalability of the protocol versus the overhead and efficiency of processing. In both cases, these engineering decisions turned out to be painfully restrictive in the longer term.

もちろん、TCPの受信ウィンドウとIPv4アドレスの長さの両方で、デザイナーが選択したフィールドサイズは、当時は良いアイデアのように思えました。フィールドは、プロトコルの当初認識されていた使用に十分な大きさでしたが、ヘッダーがコンパクトで比較的簡単で効率的であり、当時の機械を解析するのに十分なほど小さいものでした。定義された固定サイズは、プロトコルのスケーラビリティと処理のオーバーヘッド効率との間のトレードオフを表しています。どちらの場合も、これらのエンジニアリングの決定は、長期的には痛々しいほど制限的であることが判明しました。

1.2. SDNVs for DTN Protocols

1.2. DTNプロトコル用のSDNV

In specifications for the DTN Bundle Protocol (BP) [RFC5050] and Licklider Transmission Protocol (LTP) [RFC5326], SDNVs have been used for several fields including identifiers, payload/header lengths, and serial (sequence) numbers. SDNVs were developed for use in these types of fields, to avoid sending more bytes than needed, as well as avoiding fixed sizes that may not end up being appropriate. For example, since LTP is intended primarily for use in long-delay interplanetary communications [RFC5325], where links may be fairly low in capacity, it is desirable to avoid the header overhead of routinely sending a 64-bit field where a 16-bit field would suffice. Since many of the nodes implementing LTP are expected to be beyond the current range of human spaceflight, upgrading their on-board LTP implementations to use longer values if the defined fields are found to be too short would also be problematic. Furthermore, extensions similar in mechanism to TCP's Window Scale option are unsuitable for use in DTN protocols since, due to high delays, DTN protocols must avoid handshaking and configuration parameter negotiation to the greatest extent possible. All of these reasons make the choice of SDNVs for use in DTN protocols attractive.

DTNバンドルプロトコル（BP）[RFC5050]およびLicklider Transmission Protocol（LTP）[RFC5326]の仕様では、識別子、ペイロード/ヘッダー長、シリアル（シーケンス）数を含むいくつかのフィールドにSDNVが使用されています。SDNVは、これらのタイプのフィールドで使用するために開発され、必要以上に多くのバイトを送信しないようにし、適切でない可能性のある固定サイズを避けました。たとえば、LTPは主に長距離惑星間通信[RFC5325]で使用することを目的としているため、リンクの容量はかなり低い場合があるため、16ビットの64ビットフィールドを日常的に送信するヘッダーオーバーヘッドを避けることが望ましいフィールドで十分です。LTPを実装するノードの多くは、現在の人間の宇宙飛行の範囲を超えていると予想されるため、定義されたフィールドが短すぎることが判明した場合、オンボードLTP実装をアップグレードしてより長い値を使用することも問題になります。さらに、TCPのウィンドウスケールオプションとメカニズムに類似した拡張は、DTNプロトコルでの使用には適さないため、DTNプロトコルは、可能な限り最大の範囲でハンドシェーキングと構成パラメーターのネゴシエーションを避ける必要があります。これらの理由はすべて、DTNプロトコルで使用するためのSDNVを魅力的に選択します。

1.3. SDNV Usage

1.3. SDNVの使用

In short, an SDNV is simply a way of representing non-negative integers (both positive integers of arbitrary magnitude and 0), without expending much unnecessary space. This definition allows SDNVs to represent many common protocol header fields, such as:

要するに、SDNVは、単に非陰性の整数（両方とも任意の大きさと0の正の整数と0）を表す方法であり、多くの不必要なスペースを消費することはありません。この定義により、SDNVは次のような多くの一般的なプロトコルヘッダーフィールドを表すことができます。

o Random identification fields as used in the IPsec Security Parameters Index or in IP headers for fragment reassembly (Note: the 16-bit IP ID field for fragment reassembly was recently found to be too short in some environments [RFC4963]).

o IPSECセキュリティパラメーターインデックスまたはフラグメント再組み立てのIPヘッダーで使用されるランダム識別フィールド（注：フラグメント再組み立ての16ビットIP IDフィールドは、一部の環境では短すぎることがわかりました[RFC4963]）。

o Sequence numbers as in TCP or the Stream Control Transmission Protocol (SCTP).

o TCPまたはストリーム制御伝送プロトコル（SCTP）のようなシーケンス番号。

o Values used in cryptographic algorithms such as RSA keys, Diffie-Hellman key agreement, or coordinates of points on elliptic curves.

o RSAキー、diffie-hellmanキー契約、または楕円曲線上のポイントの座標などの暗号化アルゴリズムで使用される値。

o Message lengths as used in file transfer protocols.

o ファイル転送プロトコルで使用されるメッセージの長さ。

o Nonces and cookies.

o ノンセとクッキー。

As any bitfield can be interpreted as an unsigned integer, SDNVs can also encode arbitrary-length bitfields, including bitfields representing signed integers or other data types; however, this document assumes SDNV encoding and decoding in terms of unsigned integers. Implementations may differ in the interface that they provide to SDNV encoding and decoding functions, in terms of whether the values are numeric, bitfields, etc.; this detail does not alter the representation or algorithms described in this document.

ビットフィールドは署名のない整数として解釈できるため、SDNVは署名された整数または他のデータ型を表すビットフィールドを含む任意の長さのビットフィールドをエンコードすることもできます。ただし、このドキュメントでは、署名されていない整数の観点からSDNVがエンコードおよびデコードすることを想定しています。実装は、値が数値、ビットフィールドなどであるかどうかの観点から、SDNVエンコードおよびデコード機能に提供するインターフェイスで異なる場合があります。この詳細は、このドキュメントで説明されている表現またはアルゴリズムを変更しません。

The use of SDNVs rather than fixed-length fields gives protocol designers the ability to ameliorate the consequences of making difficult-to-reverse field-sizing decisions, as the SDNV format grows and shrinks depending on the particular value encoded. SDNVs do not necessarily provide optimal encodings for values of any particular length; however, they allow protocol designers to avoid potential blunders in assigning fixed lengths and remove the complexity involved with either negotiating field lengths or constructing protocol extensions. However, if SDNVs are used to encode bitfields, it is essential that the sender and receiver have a consistent interpretation of the decoded value. This is discussed further in Section 2.

固定長のフィールドではなくSDNVを使用すると、プロトコル設計者は、SDNV形式がエンコードされた特定の値に応じて成長して縮小するにつれて、リバースサイズの決定を困難にすることの結果を改善する能力を提供します。SDNVは、特定の長さの値に対して必ずしも最適なエンコーディングを提供するわけではありません。ただし、プロトコル設計者は、固定長の割り当てにおける潜在的な失敗を回避し、フィールドの長さの交渉またはプロトコル拡張の構築に関連する複雑さを削除することができます。ただし、SDNVがビットフィールドをエンコードするために使用される場合、送信者と受信者がデコードされた値の一貫した解釈を持つことが不可欠です。これについては、セクション2でさらに説明します。

To our knowledge, at this time, no IETF transport or network-layer protocol designed for use outside of the DTN domain has proposed to use SDNVs; however, there is no inherent reason not to use SDNVs more broadly in the future. The two examples cited here, of fields that have proven too small in general Internet protocols, are only a small sampling of the much larger set of similar instances that the authors can think of. Outside the Internet protocols, within ASN.1 and previous ITU protocols, constructs very similar to SDNVs have been used for many years due to engineering concerns very similar to those facing the DTNRG.

私たちの知る限り、現時点では、DTNドメイン以外で使用するために設計されたIETFトランスポートまたはネットワーク層プロトコルは、SDNVを使用することを提案していません。ただし、将来、SDNVをより広く使用しないという固有の理由はありません。ここで引用されている2つの例は、一般的なインターネットプロトコルでは小さすぎると証明されているフィールドの例は、著者が考えることができるはるかに大きな同様のインスタンスの小さなサンプリングにすぎません。ASN.1および以前のITUプロトコル内のインターネットプロトコル以外では、DTNRGに直面しているエンジニアリングの懸念と非常によく似たエンジニアリングのため、SDNVと非常によく似た構築が長年使用されてきました。

Many protocols use a Type-Length-Value method for encoding variable-length fields (e.g., TCP's options format or many of the fields in the Internet Key Exchange Protocol version 2 (IKEv2)). An SDNV is equivalent to combining the length and value portions of this type of field, with the overhead of the length portion amortized out over the bytes of the value. The penalty paid for this in an SDNV may be several extra bytes for long values (e.g., 1024-bit RSA keys). See Section 4 for further discussion and a comparison.

多くのプロトコルは、可変長さのフィールドをエンコードするためにタイプ長値法を使用します（たとえば、TCPのオプション形式またはインターネットキーエクスチェンジプロトコルバージョン2（IKEV2）の多くのフィールド）。SDNVは、このタイプのフィールドの長さと値の部分を組み合わせて、長さ部分のオーバーヘッドを値のバイトで償却します。SDNVでこれに対して支払われたペナルティは、長い値（1024ビットRSAキーなど）に対していくつかの追加バイトである可能性があります。詳細と比較については、セクション4を参照してください。

As is shown in later sections, for large values, the current SDNV scheme is fairly inefficient in terms of space (1/8 of the bits are overhead) and not particularly easy to encode/decode in comparison to alternatives. The best use of SDNVs may often be to define the Length field of a TLV structure to be an SDNV whose value is the length of the TLV's Value field. In this way, one can avoid forcing large numbers from being directly encoded as an SDNV, yet retain the extensibility that using SDNVs grants.

後のセクションに示すように、大きな値の場合、現在のSDNVスキームは空間（ビットの1/8がオーバーヘッド）の点でかなり非効率的であり、代替と比較して特に簡単にエンコード/デコードすることはできません。SDNVの最良の使用法は、多くの場合、TLV構造の長さフィールドを、値がTLVの値フィールドの長さであるSDNVに定義することです。このようにして、SDNVとして直接エンコードされることを大量に強制することを避けることができますが、SDNVのグラントを使用して拡張性を保持します。

2. Definition of SDNVs

2. SDNVの定義

Early in the work of the DTNRG, it was agreed that the properties of an SDNV were useful for DTN protocols. The exact SDNV format used by the DTNRG evolved somewhat over time before the publication of the initial RFCs on LTP and BP. An earlier version (see the initial version of LTP Internet Draft [BRF04]) bore a resemblance to the ASN.1 [ASN1] Basic Encoding Rules (BER) [X.690] for lengths (Section 8.1.3 of X.690). The current SDNV format is the one used by ASN.1 BER for encoding tag identifiers greater than or equal to 31 (Section 8.1.2.4.2 of X.690). A comparison between the current SDNV format and the early SDNV format is made in Section 4.

DTNRGの作業の初期段階では、SDNVの特性がDTNプロトコルに役立つことが合意されました。DTNRGで使用される正確なSDNV形式は、LTPおよびBPで初期RFCSが公開される前にやや進化しました。以前のバージョン（LTPインターネットドラフト[BRF04]の初期バージョンを参照）は、長さのASN.1 [ASN1]基本エンコードルール（BER）[X.690]に似ています（X.690のセクション8.1.3）。現在のSDNV形式は、ASN.1 BERが31以上のエンコードタグ識別子に使用するものです（X.690のセクション8.1.2.4.2）。現在のSDNV形式と初期のSDNV形式の比較は、セクション4で行われます。

The format currently used is very simple. Before encoding, an integer is represented as a left-to-right bitstring beginning with its most significant bit and ending with its least significant bit. If the bitstring's length is not a multiple of 7, then the string is left-padded with zeros. When transmitted, the bits are encoded into a series of bytes. The low-order 7 bits of each byte in the encoded format are taken left-to-right from the integer's bitstring representation. The most significant bit of each byte specifies whether it is the final byte of the encoded value (when it holds a 0), or not (when it holds a 1).

現在使用されている形式は非常に簡単です。エンコードする前に、整数は、最も重要なビットから始まり、最も重要なビットで終わる左から右へのビットストリングとして表されます。ビットストリングの長さが7の倍数でない場合、文字列にはゼロが左パッドされます。送信すると、ビットは一連のバイトにエンコードされます。エンコードされた形式の各バイトの低次の7ビットは、整数のビットストリング表現から左から右側に取られます。各バイトの最も重要なビットは、エンコードされた値の最終バイト（0を保持する場合）の最終バイトであるかどうかを指定します（1を保持する場合）。

For example:

例えば：

o 1 (decimal) is represented by the bitstring "0000001" and encoded as the single byte 0x01 (in hexadecimal).

o 1（小数）は、ビットストリング「0000001」で表され、単一バイト0x01（16進数）としてエンコードされます。

o 128 is represented by the bitstring "10000001 00000000" and encoded as the bytes 0x81 followed by 0x00.

o 128は、ビットストリング「10000001 00000000」で表され、バイト0x81に続いて0x00にエンコードされます。

o Other values can be found in the test vectors of the source code in Appendix A.

o 他の値は、付録Aのソースコードのテストベクトルに記載されています。

To be perfectly clear, and avoid potential interoperability issues (as have occurred with ASN.1 BER time values), we explicitly state two considerations regarding zero-padding. (1) When encoding SDNVs, any leading (most significant) zero bits in the input number might be discarded by the SDNV encoder. Protocols that use SDNVs should not rely on leading-zeros being retained after encoding and decoding operations. (2) When decoding SDNVs, the relevant number of leading zeros required to pad up to a machine word or other natural data unit might be added. These are put in the most significant positions in order to not change the value of the number. Protocols using SDNVs should consider situations where lost zero-padding may be problematic.

完全に明確にし、潜在的な相互運用性の問題を回避するために（ASN.1 BER時間値で発生したように）、ゼロパッジングに関する2つの考慮事項を明示的に述べています。（1）SDNVをエンコードする場合、入力数の主要な（最も重要な）ゼロビットは、SDNVエンコーダーによって破棄される可能性があります。SDNVを使用するプロトコルは、操作をエンコードおよびデコードした後に保持されているリーディングゼロに依存すべきではありません。（2）SDNVをデコードする場合、機械単語または他の自然データユニットにパッドアップするのに必要な主要なゼロの関連数が追加される場合があります。これらは、数の値を変更しないために最も重要な位置に置かれます。SDNVを使用したプロトコルは、ゼロパッジングの失われた状況が問題になる可能性がある状況を考慮する必要があります。

The issues of zero-padding are particularly relevant where an SDNV is being used to represent a bitfield to be transmitted by a protocol. The specification of the protocol and any associated IANA registry should specify the allocation and usage of bit positions within the unencoded field. Unassigned and reserved bits in the unencoded field will be treated as zeros by the SDNV encoding prior to transmission. Assuming the bit positions are numbered starting from 0 at the least significant bit position in the integer representation, then if higher-numbered positions in the field contain all zeros, the encoding process may not transmit these bits explicitly (e.g., if all the bit positions numbered 7 or higher are zeros, then the transmitted SDNV can consist of just one octet). On reception, the decoding process will treat any untransmitted higher-numbered bits as zeros. To ensure correct operation of the protocol, the sender and receiver must have a consistent interpretation of the width of the bitfield. This can be achieved in various ways:

ゼロパディングの問題は、SDNVがプロトコルによって送信されるビットフィールドを表すために使用されている場合に特に関連しています。プロトコルと関連するIANAレジストリの仕様は、非エンエンコードフィールド内のビット位置の割り当てと使用を指定する必要があります。エンコードされていないフィールドの未割り当ておよび予約ビットは、送信前にSDNVエンコードによってゼロとして扱われます。ビット位置が整数表現の少なくとも有意なビット位置で0から開始されると仮定すると、フィールド内のより多くの位置がすべてのゼロが含まれている場合、エンコードプロセスはこれらのビットを明示的に送信できない場合があります（たとえば、すべてのビット位置の場合7以上の番号がゼロで、その後、送信されたSDNVは1つのオクテットで構成できます）。レセプションでは、デコードプロセスは、移動されていない高度な数のビットをゼロとして扱います。プロトコルの正しい動作を確保するには、送信者と受信者はビットフィールドの幅の一貫した解釈を持たなければなりません。これはさまざまな方法で実現できます。

o the bitfield width is implicitly defined by the version of the protocol in use in the sender and receiver,

o ビットフィールド幅は、送信者と受信機で使用されているプロトコルのバージョンによって暗黙的に定義されます。

o sending the width of the bitfield explicitly in a separate item,

o ビットフィールドの幅を別のアイテムで明示的に送信すると、

o the higher-numbered bits can be safely ignored by the receiver (e.g., because they represent optimizations), or

o より数の多いビットは、受信機によって安全に無視できます（例えば、最適化を表すため）、または

o marking the highest-numbered bit by prepending a '1' bit to the bitfield.

o ビットフィールドに「1」ビットを準備することにより、最高の数のビットをマークします。

The protocol specification must record how the consistent interpretation is achieved.

プロトコル仕様は、一貫した解釈がどのように達成されるかを記録する必要があります。

The SDNV encoding technique is also known as Variable Byte Encoding (see Section 5.3.1 of [Manning09]) and is equivalent to Base-128 Elias Gamma Encoding (see Section 5.3.2 of [Manning09] and Section 3.5 of [Sayood02]). However, the primary motivation for SDNVs is to provide an extensible protocol framework rather than optimal data compression, which is the motivation behind the other uses of the technique. [Manning09] points out that the key feature of this encoding is that it is "prefix free" meaning that no code is a prefix of any other, which is an alternative way of expressing the self-delimiting property.

SDNVエンコーディング手法は、可変バイトエンコード（[Manning09]のセクション5.3.1を参照）としても知られており、基本-128エリアスガンマエンコードに相当します（[Manning09]のセクション5.3.2および[Sayood02]のセクション3.5を参照）。ただし、SDNVの主な動機は、最適なデータ圧縮ではなく、拡張可能なプロトコルフレームワークを提供することです。これは、手法の他の使用の背後にある動機です。[Manning09]は、このエンコードの重要な特徴は、それが「接頭辞フリー」であることを意味していることを指摘しています。つまり、コードは他のどのプレフィックスでもないことを意味します。

3. Basic Algorithms

3. 基本的なアルゴリズム

This section describes some simple algorithms for creating and parsing SDNV fields. These may not be the most efficient algorithms possible, however, they are easy to read, understand, and implement. Appendix A contains Python source code implementing the routines described here. The algorithms presented here are convenient for converting between an internal data block and serialized data stream associated with a transmission device. Other approaches are possible with different efficiencies and trade-offs.

このセクションでは、SDNVフィールドを作成および解析するためのいくつかの簡単なアルゴリズムについて説明します。これらは可能な限り最も効率的なアルゴリズムではないかもしれませんが、読み、理解し、実装するのは簡単です。付録Aには、ここで説明するルーチンを実装するPythonソースコードが含まれています。ここに示されているアルゴリズムは、内部データブロックと送信デバイスに関連付けられたシリアル化データストリーム間を変換するのに便利です。他のアプローチは、さまざまな効率とトレードオフで可能です。

3.1. Encoding Algorithm

3.1. エンコードアルゴリズム

There is a very simple algorithm for the encoding operation that converts a non-negative integer (value n, of length 1+floor(log n) bits) into an SDNV. This algorithm takes n as its only argument and returns a string of bytes:

非陰性整数（値n、長さ1フロア（log n）ビット）をSDNVに変換するエンコード操作には、非常に単純なアルゴリズムがあります。このアルゴリズムはnをその唯一の引数として取得し、バイトの文字列を返します。

o (Initial Step) Set a variable X to a byte sharing the least significant 7 bits of n, and with 0 in the most significant bit, and a variable Y to n, right-shifted by 7 bits.

o （初期ステップ）変数xをAに設定し、nの最小7ビットを共有し、最も重要なビットで0とnからnの変数yを共有し、7ビットで右シフトします。

o (Recursion Step) If Y == 0, return X. Otherwise, set Z to the bitwise-or of 0x80 with the 7 least significant bits of Y, and append Z to X. Right-shift Y by 7 bits and repeat the Recursion Step.

o （再帰ステップ）y == 0の場合、xを返します。それ以外の場合は、zを7ビットでzにビットワイズまたは0x80に設定し、xをxに追加します。ステップ。

This encoding algorithm has a time complexity of O(log n), since it takes a number of steps equal to ceil(n/7), and no additional space beyond the size of the result (8/7 log n) is required. One aspect of this algorithm is that it assumes strings can be efficiently appended to new bytes. One way to implement this is to allocate a buffer for the expected length of the result and fill that buffer one byte at a time from the right end.

このエンコードアルゴリズムには、O（log n）の時間の複雑さがあります。これは、天井（n/7）に等しいいくつかのステップが必要であり、結果のサイズ（8/7 log n）を超える追加スペースが必要ないためです。このアルゴリズムの1つの側面は、文字列が新しいバイトに効率的に追加できると仮定することです。これを実装する1つの方法は、結果の予想される長さにバッファーを割り当て、そのバッファーを右端から一度にバッファーすることです。

If, for some reason, an implementation requires an encoded SDNV to be some specific length (possibly related to a machine word), any leftmost zero-padding included needs to properly set the high-order bit in each byte of padding.

何らかの理由で、実装でエンコードされたSDNVが特定の長さ（おそらくマシンワードに関連する可能性がある）を必要とする場合、パディングの各バイトに高次ビットを適切に設定するための左端のゼロパッジングが含まれます。

3.2. Decoding Algorithm

3.2. デコードアルゴリズム

Decoding SDNVs is a more difficult operation than encoding them, due to the fact that no bound on the resulting value is known until the SDNV is parsed, at which point the value itself is already known. This means that if space is allocated in advance to hold the value that results from decoding an SDNV, in general, it is not known whether this space will be large enough until it is 7 bits away from being overflowed. However, as specified in Section 3.3, protocols using SDNVs must specify the largest number of bits that an implementation is expected to handle, which mitigates this problem.

SDNVをデコードすることは、SDNVが解析されるまで結果の値に縛られていないため、それらをエンコードするよりも難しい操作です。これは、SDNVのデコードから生じる値を保持するためにスペースが事前に割り当てられた場合、一般に、このスペースがオーバーフローから7ビット離れているまで十分に大きくなるかどうかは不明です。ただし、セクション3.3で指定されているように、SDNVを使用したプロトコルは、実装が処理すると予想される最大数のビットを指定する必要があります。これにより、この問題が軽減されます。

o (Initial Step) Set the result to 0. Set an index to the first byte of the encoded SDNV.

o （初期ステップ）結果を0に設定します。エンコードされたSDNVの最初のバイトにインデックスを設定します。

o (Recursion Step) Shift the result left 7 bits. Add the low-order 7 bits of the value at the index to the result. If the high-order bit under the pointer is a 1, advance the index by one byte within the encoded SDNV and repeat the Recursion Step, otherwise return the current value of the result.

o （再帰ステップ）結果を残して7ビットを左にシフトします。結果のインデックスに値の低次の7ビットを追加します。ポインターの下の高次ビットが1の場合、エンコードされたSDNV内で1バイトでインデックスを前進させ、再帰ステップを繰り返し、それ以外の場合は結果の現在の値を返します。

This decoding algorithm takes no more additional space than what is required for the result (7/8 the length of the SDNV) and the pointer. The complication is that before the result can be left-shifted in the Recursion Step, an implementation needs to first make sure that this will not cause any bits to be lost, and re-allocate a larger piece of memory for the result, if required. The pure time complexity is the same as for the encoding algorithm given, but if re-allocation is needed due to the inability to predict the size of the result, decoding may be slower.

このデコードアルゴリズムは、結果に必要なもの（SDNVの長さ7/8）とポインターよりも追加のスペースをとることはありません。合併症は、結果を再帰ステップで放置する前に、実装が最初にビットが失われないことを確認し、必要に応じて結果の大きなメモリを再割り当てする必要があることを確認する必要があるということです。。純粋な時間の複雑さは、指定されたエンコードアルゴリズムの場合と同じですが、結果のサイズを予測できないために再配置が必要な場合、デコードは遅くなる可能性があります。

These decoding steps include removal of any leftmost zero-padding that might be used by an encoder to create encodings of a certain length.

これらのデコード手順には、特定の長さのエンコーディングを作成するためにエンコーダーによって使用される可能性のある左端のゼロパッジングの削除が含まれます。

3.3. Limitations of Implementations

3.3. 実装の制限

Because of efficiency considerations or convenience of internal representation of decoded integers, implementations may choose to limit the number of bits in SDNVs that they will handle. To avoid interoperability problems, any protocol that uses SDNVs must specify the largest number of bits in an SDNV that an implementation of that protocol is expected to handle.

デコードされた整数の内部表現の効率的な考慮事項または利便性のため、実装は、それらが処理するSDNVのビット数を制限することを選択する場合があります。相互運用性の問題を回避するために、SDNVを使用するプロトコルは、そのプロトコルの実装が処理されると予想されるSDNVで最大数のビットを指定する必要があります。

For example, Section 4.1 of [RFC5050] specifies that implementations of the DTN Bundle Protocol are not required to handle SDNVs with more than 64 bits in their unencoded value. Accordingly, integer values transmitted in SDNVs have an upper limit and SDNV-encoded flag fields must be limited to 64 bit positions in any future revisions of the protocol unless the restriction is altered.

たとえば、[RFC5050]のセクション4.1は、DTNバンドルプロトコルの実装が、ENCODED値の64ビット以上のSDNVを処理するために必要ではないことを指定しています。したがって、SDNVに送信される整数値には上限があり、SDNVエンコードされたフラグフィールドは、制限が変更されない限り、プロトコルの将来の改訂で64ビット位置に制限する必要があります。

4. Comparison to Alternatives

4. 代替案との比較

This section compares three alternative ways of implementing the concept of SDNVs: (1) the TLV scheme commonly used in the Internet family, and many other families of protocols, (2) the old style of SDNVs (both the SDNV-8 and SDNV-16) defined in an early stage of LTP's development [BRF04], and (3) the current SDNV format.

このセクションでは、SDNVの概念を実装する3つの代替方法を比較します。（1）インターネットファミリーで一般的に使用されるTLVスキーム、および他の多くのプロトコルファミリー、（2）SDNVの古いスタイル（SDNV-8およびSDNV-の両方）16）LTPの開発の初期段階[BRF04]、および（3）現在のSDNV形式で定義されています。

The TLV method uses two fixed-length fields to hold the Type and Length elements that then imply the syntax and semantics of the Value element. This is only similar to an SDNV in that the value element can grow or shrink within the bounds capable of being conveyed by the Length field. Two fundamental differences between TLVs and SDNVs are that through the Type element, TLVs also contain some notion of what their contents are semantically, while SDNVs are simply generic non-negative integers, and protocol engineers still have to choose fixed-field lengths for the Type and Length fields in the TLV format.

TLVメソッドは、2つの固定長フィールドを使用して、型要素と長さの要素を保持し、値要素の構文とセマンティクスを意味します。これは、値要素が長さフィールドで伝達できる境界内で成長または縮小できるという点で、SDNVにのみ似ています。TLVとSDNVの2つの根本的な違いは、タイプ要素を介して、TLVがその内容が意味的にあるものの概念も含まれていることですが、SDNVは単に一般的な非陰性整数であり、プロトコルエンジニアはまだタイプの固定フィールドの長さを選択する必要があります。TLV形式の長さフィールド。

Some protocols use TLVs where the value conveyed within the Length field needs to be decoded into the actual length of the Value field. This may be accomplished through simple multiplication, left-shifting, or a look-up table. In any case, this tactic limits the granularity of the possible Value lengths, and can contribute some degree of bloat if Values do not fit neatly within the available decoded Lengths.

一部のプロトコルは、長さフィールド内で伝達される値を値フィールドの実際の長さにデコードする必要があるTLVを使用します。これは、単純な乗算、左シフト、またはルックアップテーブルによって達成される場合があります。いずれにせよ、この戦術は、可能な値の長さの粒度を制限し、値が利用可能なデコードされた長さにきちんと当てはまらない場合、ある程度の膨満感に寄与する可能性があります。

In the SDNV format originally used by LTP, parsing the first byte of the SDNV told an implementation how much space was required to hold the contained value. There were two different types of SDNVs defined for different ranges of use. The SDNV-8 type could hold values up to 127 in a single byte, while the SDNV-16 type could hold values up to 32,767 in 2 bytes. Both formats could encode values requiring up to N bytes in N+2 bytes, where N<127. The major difference between this old SDNV format and the current SDNV format is that the new format is not as easily decoded as the old format was, but the new format also has absolutely no limitation on its length.

もともとLTPが使用していたSDNV形式では、SDNVの最初のバイトを解析すると、含まれる値を保持するために必要なスペースが実装されました。さまざまな使用範囲に対して定義された2種類のSDNVがありました。SDNV-8タイプは、単一のバイトで最大127の値を保持できますが、SDNV-16タイプは2バイトで最大32,767を保持できます。どちらの形式も、n 2バイトで最大nバイトを必要とする値をエンコードできます。ここで、n <127です。この古いSDNV形式と現在のSDNV形式の主な違いは、新しい形式が古い形式ほど簡単にデコードされていないことですが、新しい形式にはその長さにもまったく制限がありません。

The advantage in ease of parsing the old format manifests itself in two aspects: (1) the size of the value is determinable ahead of time, in a way equivalent to parsing a TLV, and (2) the actual value is directly encoded and decoded, without shifting and masking bits as is required in the new format. For these reasons, the old format requires less computational overhead to deal with, but is also very limited in that it can only hold a 1024-bit number, at maximum. Since according to IETF Best Current Practices, an asymmetric cryptography key needed to last for a long term requires using moduli of over 1228 bits [RFC3766], this could be seen as a severe limitation of the old style of SDNVs, from which the currently used style does not suffer.

古い形式の解析の容易さの利点は、2つの側面に現れます。（1）値のサイズは、TLVを解析するのと同等の方法で、値のサイズが事前に決定可能であり、（2）実際の値は直接エンコードされてデコードされます、新しい形式で必要とされるように、ビットをシフトしてマスキングすることなく。これらの理由から、古い形式では、対処するために必要な計算オーバーヘッドが少なくなりますが、最大で1024ビット数しか保持できないという点では非常に限られています。IETFの最良の現在のプラクティスによれば、長期的に持続するために必要な非対称暗号化キーは、1228ビットを超えるモジュリを使用する必要があるため、これは現在使用されているSDNVの古いスタイルの厳しい制限と見なされる可能性があります。スタイルは苦しみません。

Table 1 compares the maximum values that can be encoded into SDNVs of various lengths using the old SDNV-8/16 method and the current SDNV method. The only place in this table where SDNV-16 is used rather than SDNV-8 is in the 2-byte row. Starting with a single byte, the two methods are equivalent, but when using 2 bytes, the old method is a more compact encoding by one bit. From 3 to 7 bytes of length though, the current SDNV format is more compact, since it only requires one bit per byte of overhead, whereas the old format used a full byte. Thus, at 8 bytes, both schemes are equivalent in efficiency since they both use 8 bits of overhead. Up to 129 bytes, the old format is more compact than the current one, although after this, limit it becomes unusable.

表1は、古いSDNV-8/16メソッドと現在のSDNVメソッドを使用して、さまざまな長さのSDNVにエンコードできる最大値を比較しています。SDNV-8ではなくSDNV-16が使用されるこのテーブルの唯一の場所は、2バイトの行にあります。単一のバイトから始めて、2つの方法は同等ですが、2バイトを使用する場合、古い方法はよりコンパクトなエンコードです。3から7バイトの長さでは、現在のSDNV形式は、オーバーヘッドのバイトごとに1ビットしか必要ないため、古い形式は完全なバイトを使用しているため、よりコンパクトです。したがって、8バイトでは、両方とも8ビットのオーバーヘッドを使用するため、両方のスキームは効率が同等です。最大129バイトまで、古い形式は現在のバイトよりもコンパクトですが、この後は使用できなくなります。

   +-------+---------------+-------------+---------------+-------------+
   | Bytes |   SDNV-8/16   |     SDNV    |   SDNV-8/16   |     SDNV    |
   |       | Maximum Value |   Maximum   | Overhead Bits |   Overhead  |
   |       |               |    Value    |               |     Bits    |
   +-------+---------------+-------------+---------------+-------------+
   |   1   |      127      |     127     |       1       |      1      |
   |       |               |             |               |             |
   |   2   |     32,767    |    16,383   |       1       |      2      |
   |       |               |             |               |             |
   |   3   |     65,535    |  2,097,151  |       8       |      3      |
   |       |               |             |               |             |
   |   4   |    2^24 - 1   |   2^28 - 1  |       8       |      4      |
   |       |               |             |               |             |
   |   5   |    2^32 - 1   |   2^35 - 1  |       8       |      5      |
   |       |               |             |               |             |
   |   6   |    2^40 - 1   |   2^42 - 1  |       8       |      6      |
   |       |               |             |               |             |
   |   7   |    2^48 - 1   |   2^49 - 1  |       8       |      7      |
   |       |               |             |               |             |
   |   8   |    2^56 - 1   |   2^56 - 1  |       8       |      8      |
   |       |               |             |               |             |
   |   9   |    2^64 - 1   |   2^63 - 1  |       8       |      9      |
   |       |               |             |               |             |
   |   10  |    2^72 - 1   |   2^70 - 1  |       8       |      10     |
   |       |               |             |               |             |
   |   16  |   2^120 - 1   |  2^112 - 1  |       8       |      16     |
   |       |               |             |               |             |
   |   32  |   2^248 - 1   |  2^224 - 1  |       8       |      32     |
   |       |               |             |               |             |
   |   64  |   2^504 - 1   |  2^448 - 1  |       8       |      64     |
   |       |               |             |               |             |
   |  128  |   2^1016 - 1  |  2^896 - 1  |       8       |     128     |
   |       |               |             |               |             |
   |  129  |   2^1024 - 1  |  2^903 - 1  |       8       |     129     |
   |       |               |             |               |             |
   |  130  |      N/A      |  2^910 - 1  |      N/A      |     130     |
   |       |               |             |               |             |
   |  256  |      N/A      |  2^1792 - 1 |      N/A      |     256     |
   +-------+---------------+-------------+---------------+-------------+

Table 1

表1

Suggested usages of the SDNV format that leverage its strengths and limit the effects of its weaknesses are discussed in Section 1.3.

強度を活用し、弱点の影響を制限するSDNV形式の推奨使用法については、セクション1.3で説明します。

Another aspect of the comparison between SDNVs and alternatives using fixed-length fields is the result of errors in transmission. Bit-errors in an SDNV can result in either errors in the decoded value, or parsing errors in subsequent fields of the protocol. In fixed-length fields, bit errors always result in errors to the decoded value rather than parsing errors in subsequent fields. If the decoded values from either type of field encoding (SDNV or fixed-length) are used as indexes, offsets, or lengths of further fields in the protocol, similar failures result.

SDNVと固定長フィールドを使用した代替案との比較のもう1つの側面は、送信のエラーの結果です。SDNVのビットエラーは、デコードされた値のエラー、またはプロトコルの後続のフィールドでの解析エラーのいずれかをもたらす可能性があります。固定長のフィールドでは、ビットエラーは常に、後続のフィールドでエラーを解析するのではなく、デコードされた値にエラーをもたらします。いずれかのタイプのフィールドエンコード（SDNVまたは固定長）からのデコードされた値が、プロトコル内のインデックス、オフセット、またはさらにフィールドの長さとして使用される場合、同様の障害が生じます。

5. Security Considerations

5. セキュリティに関する考慮事項

The only security considerations with regard to SDNVs are that code that parses SDNVs should have bounds-checking logic and be capable of handling cases where an SDNV's value is beyond the code's ability to parse. These precautions can prevent potential exploits involving SDNV decoding routines.

SDNVに関する唯一のセキュリティ上の考慮事項は、SDNVを解析するコードが境界チェックロジックを持ち、SDNVの値がコードの解析能力を超えているケースを処理できるコードです。これらの注意事項は、SDNVデコードルーチンを含む潜在的なエクスプロイトを防ぐことができます。

Stephen Farrell noted that very early definitions of SDNVs also allowed negative integers. This was considered a potential security hole, since it could expose implementations to underflow attacks during SDNV decoding. There is a precedent in that many existing TLV decoders map the Length field to a signed integer and are vulnerable in this way. An SDNV decoder should be based on unsigned types and not have this issue.

Stephen Farrellは、SDNVの非常に初期の定義でも負の整数が許可されていると指摘しました。これは、SDNVデコード中に実装をアンダーフロー攻撃に公開できるため、潜在的なセキュリティホールと見なされました。多くの既存のTLVデコーダーが長さフィールドを署名された整数にマッピングし、この方法で脆弱であるという先例があります。SDNVデコーダーは、署名されていないタイプに基づいている必要があり、この問題はありません。

6. Acknowledgements

6. 謝辞

Scott Burleigh, Manikantan Ramadas, Michael Demmer, Stephen Farrell, and other members of the IRTF DTN Research Group contributed to the development and usage of SDNVs in DTN protocols. George Jones and Keith Scott from Mitre, Lloyd Wood, Gerardo Izquierdo, Joel Halpern, Peter TB Brett, Kevin Fall, and Elwyn Davies also contributed useful comments on and criticisms of this document. DTNRG last call comments on the document were sent to the mailing list by Lloyd Wood, Will Ivancic, Jim Wyllie, William Edwards, Hans Kruse, Janico Greifenberg, Teemu Karkkainen, Stephen Farrell, and Scott Burleigh. Further constructive comments from Dave Crocker, Lachlan Andrew, and Michael Welzl were incorporated.

Scott Burleigh、Manikantan Ramadas、Michael Demmer、Stephen Farrell、およびIRTF DTN Research Groupの他のメンバーは、DTNプロトコルでのSDNVの開発と使用に貢献しました。マイターのジョージ・ジョーンズとキース・スコット、ロイド・ウッド、ジェラルド・イズキエルド、ジョエル・ハルパーン、ピーターTBブレット、ケビンフォール、エルウィンデイビスも、この文書に対する有用なコメントと批判を提供しました。DTNRGの最後のコールコメントは、Lloyd Wood、Will Ivancic、Jim Wyllie、William Edwards、Hans Kruse、Janico Greifenberg、Teemu Karkkainen、Steemen Farrell、Scott Burleighによってメーリングリストに送信されました。Dave Crocker、Lachlan Andrew、Michael Welzlからのさらなる建設的なコメントが組み込まれました。

Work on this document was performed at NASA's Glenn Research Center, in support of the NASA Space Communications Architecture Working Group (SCAWG), NASA's Earth Science Technology Office (ESTO), and the FAA/Eurocontrol Future Communications Study (FCS) in the 2005-2007 time frame, while the editor was an employee of Verizon Federal Network Systems.

このドキュメントの作業は、NASA宇宙コミュニケーションアーキテクチャワーキットグループ（SCAWG）、NASAの地球科学技術オフィス（ESTO）、および2005年のFAA/Eurocontrol Future Communications Study（FCS）を支援するために、NASAのGlenn Research Centerで実施されました。2007年の時間枠、編集者はVerizon Federal Network Systemsの従業員でした。

7. Informative References

7. 参考引用

[ASN1] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1). Specification of Basic Notation", ISO/IEC 8824-1:2002, 2002.

[asn1] itu-t rec。X.680、「要約構文表記1（ASN.1）。基本表記の仕様」、ISO/IEC 8824-1：2002、2002。

[BRF04] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider Transmission Protocol", Work in Progress, May 2004.

[BRF04] Burleigh、S.、Ramadas、M。、およびS. Farrell、「Licklider Transmission Protocol」、2004年5月の作業。

[Hain05] Hain, T., "A Pragmatic Report on IPv4 Address Space Consumption", Internet Protocol Journal Vol. 8, No. 3, September 2005.

[Hain05] Hain、T。、「IPv4アドレス空間消費に関する実用的なレポート」、Internet Protocol Journal Vol。8、No。3、2005年9月。

[IEN21] Cerf, V. and J. Postel, "Specification of Internetwork Transmission Control Program: TCP Version 3", Internet Experimental Note 21, January 1978.

[IEN21] Cerf、V。およびJ. Postel、「インターネットワーク伝送制御プログラムの仕様：TCPバージョン3」、インターネット実験ノート21、1978年1月。

[Manning09] Manning, c., Raghavan, P., and H. Schuetze, "Introduction to Information Retrieval", Cambridge University Press ISBN-13: 978-0521865715, 2009, <http://informationretrieval.org/>.

[Manning09] Manning、c。、Raghavan、P。、およびH. Schuetze、「情報検索入門」、ケンブリッジ大学出版局ISBN-13：978-0521865715、2009、<http://informationretrieval.org/>。

[RFC0713] Haverty, J., "MSDTP-Message Services Data Transmission Protocol", RFC 713, April 1976.

[RFC0713] Haverty、J。、「MSDTP-Message Services Data Transmission Protocol」、RFC 713、1976年4月。

[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。

[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.

[RFC1323] Jacobson、V.、Braden、B。、およびD. Borman、「TCP拡張のためのTCP拡張」、RFC 1323、1992年5月。

[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.

[RFC2993] Hain、T。、「Natの建築的意味」、RFC 2993、2000年11月。

[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.

[RFC3766] Orman、H。およびP. Hoffman、「対称キーの交換に使用される公共キーの強度の決定」、BCP 86、RFC 3766、2004年4月。

[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, July 2007.

[RFC4963] Heffner、J.、Mathis、M。、およびB. Chandler、「IPv4の高データレートでの再組み立てエラー」、RFC 4963、2007年7月。

[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.

[RFC5050] Scott、K。およびS. Burleigh、「バンドルプロトコル仕様」、RFC 5050、2007年11月。

[RFC5325] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider Transmission Protocol - Motivation", RFC 5325, September 2008.

[RFC5325] Burleigh、S.、Ramadas、M。、およびS. Farrell、「Licklider Transmission Protocol -Motivation」、RFC 5325、2008年9月。

[RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider Transmission Protocol - Specification", RFC 5326, September 2008.

[RFC5326] Ramadas、M.、Burleigh、S。、およびS. Farrell、「Licklider Transmission Protocol -Specification」、RFC 5326、2008年9月。

[Sayood02] Sayood, K., "Lossless Data Compression", Academic Press ISBN-13: 978-0126208610, December 2002, <http://books.google.co.uk/books?id=LjQiGwyabVwC>.

[Sayood02] Sayood、K。、「ロスレスデータ圧縮」、アカデミックプレスISBN-13：978-0126208610、2002年12月、<http://books.google.co.uk/books?id=ljqigwyabvwc>。

[X.690] ITU-T Rec. X.690, "Abstract Syntax Notation One (ASN.1). Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ISO/IEC 8825-1:2002, 2002.

[x.690] itu-t rec。X.690、「要約構文表記1（ASN.1）。エンコーディングルール：基本エンコードルール（BER）、標準エンコードルール（CER）および識別型エンコードルール（DER）の仕様」、ISO/IEC 8825-1：2002、2002年。

Appendix A. SDNV Python Source Code

付録A. SDNV Pythonソースコード

   #  This code may be freely copied.  Attribution would be appreciated.
   #
   # sdnv_decode() takes a string argument (s), which is assumed to be
   #   an SDNV, and optionally a number (slen) for the maximum number of
   #   bytes to parse from the string.  The function returns a pair of
   #   the non-negative integer n that is the numeric value encoded in
   #   the SDNV, and integer that is the distance parsed into the input
   #   string.  If the slen argument is not given (or is not a non-zero
   #   number) then, s is parsed up to the first byte whose high-order
   #   bit is 0 -- the length of the SDNV portion of s does not have to
   #   be pre-computed by calling code.  If the slen argument is given
   #   as a non-zero value, then slen bytes of s are parsed.  The value
   #   for n of -1 is returned for any type of parsing error.
   #
   # NOTE: In python, integers can be of arbitrary size.  In other
   #   languages, such as C, SDNV-parsing routines should take
   #   precautions to avoid overflow (e.g., by using the Gnu MP library,
   #   or similar).
   #
   def sdnv_decode(s, slen=0):
     n = long(0)
     for i in range(0, len(s)):
       v = ord(s[i])
       n = n<<7
       n = n + (v & 0x7F)
       if v>>7 == 0:
         slen = i+1
         break
       elif i == len(s)-1 or (slen != 0 and i > slen):
         n = -1 # reached end of input without seeing end of SDNV
     return (n, slen)

# sdnv_encode() returns the SDNV-encoded string that represents n. # An empty string is returned if n is not a non-negative integer def sdnv_encode(n): r = "" # validate input if n >= 0 and (type(n) in [type(int(1)), type(long(1))]): flag = 0 done = False while not done: # encode lowest 7 bits from n newbits = n & 0x7F n = n>>7 r = chr(newbits + flag) + r if flag == 0:

＃SDNV_ENCODE（）nを表すSDNVエンコード文字列を返します。＃nが非陰性整数def sdnv_encode（n）：r = ""＃[type（int（1））のtype（n）のif and（n）を検証する場合、空の文字列が返されます。（long（1））]：flag = 0 done = false while not not：＃n newbits = n＆0x7f n = n >> 7 r = chr（newbits flag）r flag == 0の最低7ビットをエンコード：

flag = 0x80 if n == 0: done = True return r

flag = 0x80 if n == 0：done = true return r

   # test cases from LTP and BP internet-drafts, only print failures
   def sdnv_test():
     tests = [(0xABC, chr(0x95) + chr(0x3C)),
              (0x1234, chr(0xA4) + chr (0x34)),
              (0x4234, chr(0x81) + chr(0x84) + chr(0x34)),
              (0x7F, chr(0x7F))]

     for tp in tests:
       # test encoding function
       if sdnv_encode(tp[0]) != tp[1]:
         print "sdnv_encode fails on input %s" % hex(tp[0])
       # test decoding function
       if sdnv_decode(tp[1])[0] != tp[0]:
         print "sdnv_decode fails on input %s, giving %s" % \
               (hex(tp[0]), sdnv_decode(tp[1]))

Authors' Addresses

著者のアドレス

Wesley M. Eddy MTI Systems NASA Glenn Research Center MS 500-ASRC; 21000 Brookpark Rd Cleveland, OH 44135

Wesley M. Eddy MTI Systems NASA Glenn Research Center MS 500-ASRC;21000 Brookpark Rd Cleveland、OH 44135

Phone: 216-433-6682 EMail: wes@mti-systems.com

電話：216-433-6682メール：wes@mti-systems.com

Elwyn Davies Folly Consulting Soham UK

Phone: EMail: elwynd@folly.org.uk URI:

電話：電子メール：elwynd@folly.org.uk uri：