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

URL : https://tools.ietf.org/html/rfc6256
タイトル : 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.

自己区切り数値値（SDNVs）が最近提案遅延耐性ネットワークプロトコルでフィールド型として導入されています。 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.

この文書はインターネットResearch Task Force（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.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6256で取得することができます。

著作権表示

著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。

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.

この文書はインターネットResearch Task Force（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プロトコルで使用するために提案されている自己区切り数値値（SDNVs）上のいくつかの背景を提供し、他のネットワークプロトコルでその潜在的な適用に動機を与えます。 DTNRGは、それが解決しようとする課題に対応するためにSDNVsを作成しました、そして、SDNVsが密接にASN.1内の特定の構築物及びさらに古いITUプロトコルに似ていることが指摘されているので、問題は、新規またはDTNに固有のものではありません。他の機構は、ASN.1符号化規則とHavertyメッセージサービスデータ伝送プロトコル（MSDTP）[RFC0713]などのより複雑なデータ構造を符号化するために開発されてきたがSDNVsは、数値またはビット文字列に厳密に焦点を当てます。このため、焦点の、SDNVsはすぐにコードの少量のみで実現することができます。

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.

SDNVsは簡潔DTNRGにおける文書作成の流れに起因するバンドルプロトコル[RFC5050]とリックライダー伝送プロトコル（LTP）[RFC5326]の仕様、の両方で定義されています。この文書では、明確にし、さらにSDNVsの背後にある動機とエンジニアリングの意思決定を説明しています。

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-宣伝受信ウィンドウと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セグメントは、約65キロバイト最大値を符号化する、16ビット[RFC0793]に固定されている受信広告ウィンドウフィールドを含みます。この値の目的は、受信機がそのピアは、このように、受信機は、そのバッファのサイズを制限することができ、いつでも（不承認）非凡有することができるバイトの数を送信指定することを可能にすることによって、フロー制御を提供することです。ネットワーク速度は、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アドレスは、（歴史的ノート、120ビットまでの8ビットの倍数で使用される可変長アドレス[IEN21]にIPヘッダフォーマット仕様の初期バージョンとして）32ビット[RFC0791]に固定されています。そのサブネットとアドレスブロックの割り当てが行われたように、IPv4アドレスの数は、インターネット[Hain05]の成長の限界と見られています。この問題を解決するには、2つの発散のパスがネットワークアドレス変換器（NAT）の使用とIPv6の開発となっています。 NATは、他の多くのプロトコルが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プロトコルのSDNVs

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]とリックライダー伝送プロトコル（LTP）の仕様[RFC5326]において、SDNVsは、識別子、ペイロード/ヘッダ長、およびシリアル（シーケンス）番号を含むいくつかの分野に使用されてきました。 SDNVsは、必要以上のバイトを送信するだけでなく、適切になってしまうかもしれない、固定サイズを避け避けるために、フィールドのこれらのタイプで使用するために開発されました。 LTPは、リンク容量がかなり低いかもしれ長い遅延惑星間通信[RFC5325]での使用のために主に意図されているので、例えば、日常16ビットの64ビットのフィールドを送信するヘッダのオーバーヘッドを回避することが望ましいですフィールドが十分であろう。 LTPを実装するノードの多くは人間の宇宙飛行の現在の範囲を超えることが予想されるので、定義されたフィールドが短すぎることが判明している場合は、より長い値を使用するようにオンボードLTP実装をアップグレードすることも問題となります。高い遅延のため、DTNプロトコルを最大限にハンドシェイクし、設定パラメータのネゴシエーションを避けなければならない、ので、TCPのウィンドウスケールオプションのメカニズムで同様の拡張機能は、DTNプロトコルでの使用には適していません。これらの理由のすべてが魅力的なDTNプロトコルで使用するためSDNVsの選択をします。

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の正の整数の両方を）表す方法です。この定義はSDNVsのような多くの一般的なプロトコルのヘッダフィールドを表すことを可能にします。

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]).

IPsecのセキュリティパラメータインデックスまたはフラグメント再構成のためにIPヘッダーで使用されるランダム識別フィールドO（注：断片再組み立てのための16ビットIP IDフィールドが、最近、いくつかの環境では短すぎることが見出された[RFC4963]）。

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

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

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

O値は、RSAキー、ディフィー・ヘルマン鍵合意、または楕円曲線上の点の座標のような暗号化アルゴリズムで使用されます。

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.

任意のビットフィールドは符号なし整数として解釈することができるように、SDNVsも符号付き整数または他のデータ・タイプを表すビットフィールドを含む任意の長さのビットフィールドを符号化することができます。しかし、この文書では、符号なし整数の面で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フォーマットが成長し、符号化された特定の値に応じて収縮するようSDNVsなく、固定長フィールドの使用は、プロトコル設計者に困難な逆電界サイジング意思決定の結果を改善する能力を与えます。 SDNVsは、必ずしも任意の特定の長さの値のための最適なエンコーディングを提供しません。しかし、彼らは、プロトコル設計者が一定の長さを割り当てることで潜在的な失策を回避し、フィールドの長さを交渉またはプロトコルの拡張機能を構築するのいずれかに関わる複雑さを取り除くことができます。 SDNVsは、ビットフィールドを符号化するために使用される場合は、送信者と受信者が復号された値の一貫した解釈を持っていることが不可欠です。これは、第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トランスポートまたはネットワーク層プロトコルはSDNVsを使用することを提案していません。しかし、将来的にはより広くSDNVsを使用しないようには固有の理由はありません。一般的なインターネット・プロトコルには小さすぎる証明されているフィールドのここに引用された2つの例では、筆者が考えることができる類似したインスタンスのはるかに大きいセットのほんのサンプリングされています。インターネット・プロトコルの外では、ASN.1と前のITUプロトコルの中に、SDNVsに非常によく似構築DTNRGが直面しているものと非常に類似した技術上の問題のために長年使用されてきました。

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の）内のフィールドの多くの）可変長フィールドを符号化するためなType-Length-valueメソッドを使用します。 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）空間的に非効率的ではありません。 SDNVsの最適な使用は、多くの場合、その値TLVのValueフィールドの長さであるSDNVするTLV構造の長さフィールドを定義することであってもよいです。このように、一つは直接SDNVとして符号化されるの多数を強制避ける、まだSDNVsグラントを使用して拡張性を保持することができます。

2. Definition of SDNVs

SDNVs 2.定義

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に初期RFCの出版前に、時間をかけて多少進化しました。以前のバージョン（LTPインターネットドラフト[BRF04]の初期バージョンを参照）は、長さ（X.690のセクション8.1.3）のためのASN.1 [ASN1]基本符号化規則（BER）[X.690]に類似ボア。現在SDNV形式は（X.690のセクション8.1.2.4.2）より大きいまたは31に等しいタグ識別子を符号化するためのASN.1 BERで使用されるものです。現在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ビットは、整数のビット文字列表現から、左から右に取られます。（それは1を保持している場合）、各バイトの最上位ビットは、符号化された値（それは0を保持している）の最後のバイトであるかどうかを指定する、またはしません。

For example:

例えば：

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

O 1（小数）はビット列「0000001」で表され、（16進数）は、単一のバイトが0x01として符号化されます。

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

O 128は、ビット列「10000001 00000000」で表され、0x00に続くバイト0x81ととして符号化されます。

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点を述べます。 SDNVsをコードする場合（1）、入力番号に先頭の（最上位）のゼロビットがSDNVエンコーダによって廃棄される可能性があります。リーディングゼロに頼るべきではないSDNVsを使用するプロトコルは、符号化及び復号化動作後に保持されます。 SDNVsを復号する場合（2）、機械語または他の天然のデータ部にパッドを上に必要な先行ゼロの関連数が追加されるかもしれません。これらは、数の値を変更しないために、最も重要な位置に置かれています。 SDNVsを使用したプロトコルは失わゼロパディングが問題となり得る状況を考慮する必要があります。

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.

ビットフィールドに「1」ビットを付加することにより、最高番ビットマーキングO。

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及びセクション3.5を参照[Sayood02]）と等価です。しかし、SDNVsための主要な動機は、技術の他の使用の背後にある動機である拡張可能なプロトコルの枠組みではなく、最適なデータ圧縮を提供することです。 [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:

SDNVに（長さ1 +床の値n、（n）ビットのログ）非負整数に変換する符号化処理のための非常に単純なアルゴリズムがあります。このアルゴリズムでは、唯一の引数として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（最初のステップ）最下位7 Nのビット、最上位ビットに0であり、nは、変数Yを共有バイトに変数Xを設定し、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を返し、Yの7つの最下位ビットとビット単位、または0x80でのに対してZを設定し、7ビット右シフトYをXとし、繰り返すZを追加再帰ステップ。

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.

それはCEIL（N / 7）に等しいステップの数、および要求される結果（8/7ログN）の大きさを超えない追加のスペースを取るので、この符号化アルゴリズムは、O（ログ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.

復号SDNVs起因SDNVまで知られていた値には結合したが、値自体は既に知られているこの時点で、解析されていないという事実のために、それらをコードするよりも困難な作業です。これは、スペースがSDNVをデコードした値を保持するために予め割り当てられている場合、それは7ビット離れオーバーフローされないようになるまで、一般的に、このスペースが十分に大きくなるかどうかは知られていないことを意味します。しかしながら、セクション3.3で指定されるように、SDNVsを使用してプロトコルはこの問題を緩和する実装を処理するために予想されるビットの最大数を指定しなければなりません。

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

O（最初のステップ）は、符号化されたSDNVの最初のバイトにインデックスを設定0に結果を設定します。

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.

この復号化アルゴリズムは、結果のために必要とされるものよりも多くの追加のスペース（7/8 SDNVの長さ）とポインタをとりません。合併症は、必要であれば、結果は再帰ステップで左にシフトすることができます前に、実装は、最初にこれは任意のビットが失われ、その結果のためにメモリの大きな部分を再割り当てしないことを確認する必要があることです。純粋時間計算は、与えられた符号化アルゴリズムと同じであるが、再割り当ては、結果のサイズを予測することができないことに起因して必要とされる場合、復号化は遅くてもよいです。

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.

なぜなら効率の考慮又は復号化整数の内部表現の便宜のため、実装は、それらが処理するSDNVs内のビットの数を制限することを選択することができます。相互運用性の問題を回避するために、SDNVsを使用するすべてのプロトコルは、そのプロトコルの実装を処理するために期待されていること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バンドルプロトコルの実装は、その符号化されていない値が64以上のビットでSDNVsを処理するために必要とされないことを指定します。従って、SDNVsで送信整数値が上限と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.

一般的にインターネットファミリで使用される（1）TLVスキーム、およびプロトコルの他の多くの家族、（2）SDNVsの古いスタイル（両方SDNV-8とSDNV-：このセクションでは、3つのSDNVsのコンセプトを実現するための別の方法を比較します16）[BRF04] LTPの開発の初期段階で定義され、そして（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つの固定長フィールドを使用します。 value要素は長さフィールドによって搬送されることが可能な範囲内で拡大または縮小することができるという点で、これはSDNVにだけ類似しています。 TLVとSDNVsの間に2つの基本的な違いはSDNVsは、単に一般的な非負整数であり、プロトコルのエンジニアはまだタイプのための固定フィールドの長さを選択する必要がありながら、Type要素を通じて、TLVのも、その内容が意味あるもののいくつかの概念を含んでいることがあります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.

いくつかのプロトコルは、Lengthフィールド内に搬送値がValueフィールドの実際の長さに復号される必要がある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

もともとはLTPが使用するSDNV形式では、SDNVの最初のバイトを解析することはスペースが含まれている値を保持するために必要とされたどのくらいの実装を語りました。使用の異なる範囲に対して定義されたSDNVsの2種類がありました。 SDNV-16型は2バイトで32,767までの値を保持することができながらSDNV-8タイプは、単一バイトで127までの値を保持することができました。両方の形式は、最大要求値を符号化することができ

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.

N + 2バイト、N <127でNバイト。この古い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.

TLVを解析と同等の方法で、（1）の値の大きさは、事前に決定され、（2）実際の値はそのまま符号化および復号化される：古いフォーマットを解析の容易さの利点は、二つの側面に現れます、新しいフォーマットに必要とされるビットをシフトしマスク無し。これらの理由から、古い形式はに対処するためのより少ない計算オーバーヘッドを必要とするだけでなく、非常にそれが唯一最大で、1024ビットの数を保持できるという点で限定されています。 IETFベストプラクティス現在、長期的に持続するために必要な非対称暗号キーによると、1228以上のビット[RFC3766]の弾性係数を使用して必要とするので、これは現在使用されて、そこからSDNVsの古いスタイルの厳しい制限、と見ることができますスタイルは苦しむことはありません。

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法を用いて種々の長さのSDNVsに符号化することができる最大値を比較します。 SDNV-16 SDNV-8ではなく使用され、このテーブル内の唯一の場所は、2バイトの列です。単一のバイトで始まる2つの方法は同等であるが、2つのバイトを使用する場合、従来の方法は、1ビットよりコンパクトな符号化です。しかし長さの3~7バイトから、現在SDNV形式は古い形式がフルバイトを使用するのに対し、それだけで、オーバーヘッドのバイト当たり1ビットを必要とするので、よりコンパクトです。どちらもオーバーヘッドの8ビットを使用するので、このように、8バイトで、両方の方式は効率が同等です。この後、それが使用できなくなった制限が129のバイトまでは、古いフォーマットは、現在の1よりもコンパクトです。

   +-------+---------------+-------------+---------------+-------------+
   | 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.

固定長フィールドを使用してSDNVsおよび代替形態間の比較の別の態様は、伝送中のエラーの結果です。 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.

SDNVsに関する唯一のセキュリティの考慮事項は、SDNVsは、境界チェックのロジックを持っていると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.

スティーブン・ファレルはSDNVsの非常に初期の定義はまた、負の整数を許可することを指摘しました。それは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.

スコット・バーレイ、Manikantan Ramadas、マイケルDemmer、スティーブン・ファレル、およびIRTF DTN研究グループの他のメンバーは、DTNプロトコルでSDNVsの開発と利用に貢献しました。ジョージ・ジョーンズとマイター、ロイド・ウッド、ヘラルド・Izquierdo、ジョエル・ハルパーン、ピーターTBブレット、ケビン秋からキース・スコット、とエルウィン・デイヴィスも有用でコメントや、このドキュメントの批判に貢献しました。文書上のDTNRG最後の呼び出しのコメントはロイド・ウッド、ウィルIvancic、ジムWyllie、ウィリアム・エドワーズ、ハンス・クルーゼ、Janicoグライフェンベルク、テームKarkkainen、スティーブン・ファレル、そしてスコット・バーレイによってメーリングリストに送られました。さらにデイブ・クロッカー、ラクランアンドリュー、そしてマイケル・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.

このドキュメントの作業は2005〜でNASA宇宙通信アーキテクチャワーキンググループ（SCAWG）、NASAの地球科学技術局（ESTO）、およびFAA /ユーロコントロールフューチャーコミュニケーション研究（FCS）をサポートするために、NASAのグレンリサーチセンターで行われました2007年のタイムフレーム、エディタはベライゾン連邦ネットワークシステムの従業員でした。

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勧告。 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]バーレイ、S.、Ramadas、M.、およびS.ファレル、 "リックライダー伝送プロトコル"、進歩、2004年5月での作業。

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

[Hain05]ハイン、T.、インターネット・プロトコル・ジャーナルVol「IPv4アドレス空間の消費の実用報告書」。 8、第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]サーフ、V.およびJ.ポステル、 "インターネットワーク伝送制御プログラムの仕様：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]マニング、C、ラガバン、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・メッセージ・サービス・データ伝送プロトコル"、RFC 713、1976年4月。

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

[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。

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

[RFC0793]ポステル、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]ジェーコブソン、V.、ブレーデン、B.、およびD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。

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

[RFC2993]ハイン、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]オーマン、H.、およびP.ホフマン、 "対称鍵を交換するために使用公開鍵の強さを測定"、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.、マティス、M.、およびB.チャンドラー、 "高速データレートでのIPv4の再構築エラー"、RFC 4963、2007年7月。

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

[RFC5050]スコット、K.およびS.バーリー、 "バンドルプロトコル仕様"、RFC 5050、2007年11月。

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

[RFC5325]バーレイ、S.、Ramadas、M.、およびS.ファレル、 "リックライダー伝送プロトコル - 動機"、RFC 5325、2008年9月。

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

[RFC5326] Ramadas、M.、バーレイ、S.、およびS.ファレル、 "リックライダー伝送プロトコル - 仕様"、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勧告。 X.690、 "抽象構文記法1（ASN.1）符号化規則：基本符号化規則（BER）の仕様、Canonicalの符号化規則（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_decode（）＃SDNVであると仮定される文字列引数をとり、そして必要に応じて＃の最大数の数（SLEN）文字列から解析するバイト。関数は、入力＃列に解析された距離である。＃＃SDNVで符号化数値である非負整数nの対、及び整数を返します。を有していないSのSDNV部分の長さ - SLEN引数が与えられていない（または非ゼロ＃番号ではない）である場合、次に、Sは、その上位＃ビットが0である最初のバイトまで解析され＃のコードを呼び出すことによって、事前に計算されます。 SLEN引数が非ゼロ値として＃が与えられる場合、SのSLENバイトが解析されます。 -1のnの値＃がエラーを解析の任意のタイプのために戻されます。 ##注：Pythonでは、整数は任意のサイズにすることができます。 Cのような他の＃言語で、SDNV-解析ルーチン（例えば、ヌーMPライブラリ、＃または類似を使用して）、オーバフローを回避するために、＃予防措置を取るべきです。＃1デフsdnv_decode（S、SLEN = 0）：（V = ORD（S [I]）N = N << 7 N = N + N =長（0）は、iの範囲内（0、LEN（S））のためにV＆0x7Fの）場合は、V >> 7 == 0：！SLEN = I + 1つのブレークのelif I == LEN（S）-1または（SLEN = 0とi>はSLEN）：入力のN = -1＃達して終了SDNVリターンの終わりを見ずに（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:

＃1 sdnv_encode（）は、Nを表しSDNVエンコードされた文字列を返します。 nは負でない整数デフsdnv_encodeない場合＃空の文字列が返される（N）：R = "" ＃が入力を検証する場合、N> = 0及び[タイプ（INT（1））、タイプ（型（n）（ロング（1））]）= N＆0x7FのN = Nのnewbitsから＃エンコード最下位7ビットをN = 7、R = CHR（newbits +フラグ）+ Rフラグ場合>>：行われていないがフラグ= 0 = Falseを行います= 0：

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

行わ= trueを返すのR：フラグ= 0x80をN == 0であれば

# 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))]

LTPとBPインターネットドラフトから＃のテストケースのみ印刷障害DEF sdnv_test（）：テスト= [（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]))

試験において、TPの場合：＃試験符号化関数sdnv_encodeは（TP [0]）= TP [1]の場合：印刷％ヘクス（TP [0]）＃テストデコード機能sdnv_decode（TP [なら "sdnv_encode入力％Sに失敗します" 1]）[0] = TP [0]：！プリント％の\（16進数（TP [0]）、sdnv_decode（TP [1]）） "sdnv_decodeは、％sのを与え、入力％sのに失敗しました"

Authors' Addresses

著者のアドレス

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

ウェズリーM.エディMTIシステムNASAグレンリサーチセンターMS-500 ASRC。 21000ブルックパークRdのクリーブランド、オハイオ州44135

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

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

Elwyn Davies Folly Consulting Soham UK

エルウィン・デイヴィスフォリーコンサルティングソーハム英国

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

電話番号：メールアドレス：URIをelwynd@folly.org.uk：