[要約] RFC 3843は、IPのためのRObust Header Compression（ROHC）の圧縮プロファイルに関するものです。このRFCの目的は、IPヘッダの圧縮を通じてネットワークの効率性を向上させることです。
Network Working Group L-E. Jonsson
Request for Comments: 3843 G. Pelletier
Category: Standards Track Ericsson
June 2004
RObust Header Compression (ROHC): A Compression Profile for IP
堅牢なヘッダー圧縮（ROHC）：IPの圧縮プロファイル
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
The original RObust Header Compression (ROHC) RFC (RFC 3095) defines a framework for header compression, along with compression protocols (profiles) for IP/UDP/RTP, IP/ESP (Encapsulating Security Payload), IP/UDP, and also a profile for uncompressed packet streams. However, no profile was defined for compression of IP only, which has been identified as a missing piece in RFC 3095. This document defines a ROHC compression profile for IP, similar to the IP/UDP profile defined by RFC 3095, but simplified to exclude UDP, and enhanced to compress IP header chains of arbitrary length.
元の堅牢なヘッダー圧縮（ROHC）RFC（RFC 3095）は、IP/UDP/RTP、IP/ESP（セキュリティペイロードのカプセル化）、IP/UDP、およびまた、ヘッダー圧縮のフレームワークと、圧縮プロトコル（プロファイル）を定義します。非圧縮パケットストリームのプロファイル。ただし、RFC 3095の不足しているピースとして識別されているIPのみの圧縮のプロファイルは定義されていません。このドキュメントは、RFC 3095で定義されたIP/UDPプロファイルと同様に、IPのROHC圧縮プロファイルを定義していますが、除外するように簡素化されました。UDP、および任意の長さのIPヘッダーチェーンを圧縮するように強化されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. ROHC IP Compression (Profile 0x0004) . . . . . . . . . . . . . 3
3.1. Static Chain Termination . . . . . . . . . . . . . . . . 3
3.2. Handling Multiple Levels of IP Headers . . . . . . . . . 3
3.3. Constant IP-ID . . . . . . . . . . . . . . . . . . . . . 4
3.4. Additional Mode Transition Logic . . . . . . . . . . . . 6
3.5. Initialization . . . . . . . . . . . . . . . . . . . . . 8
3.6. Packet Types . . . . . . . . . . . . . . . . . . . . . . 8
3.7. The CONTEXT_MEMORY Feedback Option . . . . . . . . . . . 10
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Detailed Procedures for Canceling Mode Transitions. . 12
A.1. Transition from Optimistic to Reliable Mode. . . . . . . 12
A.2. Transition from Unidirectional to Reliable Mode. . . . . 13
A.3. Transition from Reliable to Optimistic Mode. . . . . . . 13
A.4. Transition Back to Unidirectional Mode . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 16
The original RObust Header Compression (ROHC) RFC [RFC-3095] defines a framework for header compression, along with compression protocols (profiles) for IP/UDP/RTP, IP/ESP (Encapsulating Security Payload), IP/UDP, and also a profile for uncompressed packet streams. The profile for uncompressed data was defined to provide a means to encapsulate all traffic over a link within ROHC packets. Through this profile, the lower layers do not have to provide multiplexing for different packet types, but instead ROHC can handle any packet stream, even if compression profiles for all kinds of packet streams have not yet been defined or implemented over the link.
元の堅牢なヘッダー圧縮（ROHC）RFC [RFC-3095]は、ヘッダー圧縮のフレームワークと、IP/UDP/RTP、IP/ESP（セキュリティペイロードのカプセル化）、IP/UDPの圧縮プロトコル（プロファイル）を定義します。非圧縮パケットストリームのプロファイル。非圧縮データのプロファイルは、ROHCパケット内のリンク上のすべてのトラフィックをカプセル化する手段を提供するために定義されました。このプロファイルを通じて、下層はさまざまなパケットタイプに多重化を提供する必要はありませんが、代わりにROHCは、あらゆる種類のパケットストリームの圧縮プロファイルがリンク上にまだ定義または実装されていない場合でも、任意のパケットストリームを処理できます。
Although the profile without compression is simple and can tunnel arbitrary packets, it has of course a major weakness in that it does not compress the headers at all. When considering that normally all packets are expected to be IP [RFC-791, RFC-2460] packets, and that the IP header often represents a major part of the total header, a useful alternative to no compression would for most packets be compression of the IP header only. Unfortunately, such a profile was not defined in [RFC-3095], and this has thus been identified as an important missing piece in the ROHC toolbox.
圧縮のないプロファイルは単純で、任意のパケットをトンネルすることができますが、もちろん、ヘッダーをまったく圧縮しないという点で大きな弱点があります。通常、すべてのパケットがIP [RFC-791、RFC-2460]パケットであると予想され、IPヘッダーがトータルヘッダーの大部分を表すことが多いことを考慮する場合、ほとんどのパケットの圧縮の有用な代替手段は圧縮されます。IPヘッダーのみ。残念ながら、このようなプロファイルは[RFC-3095]で定義されていなかったため、これはROHCツールボックスの重要な欠落部分として特定されています。
This document addresses this missing compression support and defines a ROHC compression profile for IP [RFC-791, RFC-2460] only, similar to the IP/UDP profile defined by [RFC-3095], but simplified to exclude UDP. Due to the similarities with the IP/UDP profile, the IP compression profile is described based on the IP/UDP profile, mainly covering differences. The most important differences are a different way of terminating the static header chain, and the capability of compressing IP header chains of arbitrary length.
このドキュメントは、この不足している圧縮サポートに対応し、[RFC-3095]で定義されたIP/UDPプロファイルと同様に、IP [RFC-791、RFC-2460]のROHC圧縮プロファイルのみを定義しますが、UDPを除外するように簡素化されます。IP/UDPプロファイルとの類似性により、IP圧縮プロファイルは、主に違いをカバーするIP/UDPプロファイルに基づいて記述されています。最も重要な違いは、静的ヘッダーチェーンを終了する別の方法と、任意の長さのIPヘッダーチェーンを圧縮する機能です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC-2119]に記載されているように解釈される。
ROHC UDP
ROHC UDP
"ROHC UDP" in this document refers to the IP/UDP profile (Profile 0x0002) as defined in [RFC-3095].
このドキュメントの「ROHC UDP」は、[RFC-3095]で定義されているIP/UDPプロファイル（プロファイル0x0002）を指します。
In general, there are no major differences between the ROHC UDP profile and the IP profile (ROHC IP) defined in this document, since the removal of UDP has no impact on the compression mechanisms in principle. As for ROHC UDP, the compressor generates a 16-bit sequence number which increases by one for each packet compressed in the packet stream, simply called SN below. The most important difference between this profile and ROHC UDP is about static chain termination and the handling of multiple IP headers. Unless stated explicitly below, mechanisms and formats are the same as for ROHC UDP.
一般に、UDPの削除は原則として圧縮メカニズムに影響を与えないため、このドキュメントで定義されているROHC UDPプロファイルとIPプロファイル（ROHC IP）の間に大きな違いはありません。ROHC UDPについては、コンプレッサーは16ビットシーケンス番号を生成し、パケットストリームで圧縮されたパケットが1つずつ増加します。このプロファイルとROHC UDPの最も重要な違いは、静的チェーン終了と複数のIPヘッダーの取り扱いに関するものです。以下に明示的に記載されていない限り、メカニズムとフォーマットはROHC UDPと同じです。
One difference for IP-only compression, compared to IP/UDP compression, is related to the termination of the static chain in IR headers. For the UDP profile, the chain always ends with a UDP header part, which per definition provides the boundaries for the chain. The UDP header is also the last header in the uncompressed packet (except for a potential application header). For the IP-only profile, there is no single last header that per profile definition terminates the chain. Instead, the static chain is terminated if the "Next Header / Protocol" field of a static IP header part indicates anything but IP (IPinIP or IPv6). Alternatively, the compressor can choose to end the static chain at any IP header, and indicate this by setting the MSB of the IP version field to 1 (0xC for IPv4 or 0xE for IPv6). The decompressor must store this indication in the context for correct decompression of subsequent headers. Note that the IP version field in decompressed headers must be restored to its original value.
IP/UDP圧縮と比較して、IPのみの圧縮の1つの違いは、IRヘッダーの静的チェーンの終了に関連しています。UDPプロファイルの場合、チェーンは常にUDPヘッダーパーツで終わります。これは、定義ごとにチェーンの境界を提供します。UDPヘッダーは、非圧縮パケットの最後のヘッダーでもあります（潜在的なアプリケーションヘッダーを除く）。IPのみのプロファイルの場合、プロファイルごとの定義がチェーンを終了する最後のヘッダーはありません。代わりに、静的IPヘッダーパーツの「次のヘッダー /プロトコル」フィールドがIP（IPINIPまたはIPv6）以外のものを示している場合、静的チェーンが終了します。あるいは、コンプレッサーは、IPヘッダーで静的チェーンを終了することを選択し、IPバージョンフィールドのMSBを1（IPv4の場合は0xcまたはIPv6の0xe）を設定することでこれを示すことができます。減圧装置は、後続のヘッダーの正しい減圧のために、コンテキストにこの兆候を保存する必要があります。減圧ヘッダーのIPバージョンフィールドは、元の値に復元する必要があることに注意してください。
The ROHC IR and IR-DYN packets defined in [RFC-3095] are used to communicate static and/or dynamic parts of a context. For each of the compression profiles defined in [RFC-3095], there is a single last header in the header chain that clearly marks the termination of the static chain. The length of the dynamic chain is then inferred from the static chain in the IR header itself, or from the static chain in the context for the IR-DYN header. The length of both static and dynamic chains may thus be of arbitrary length and may, in theory, initialize a context with an arbitrary number of IP levels.
[RFC-3095]で定義されているROHC IRおよびIR-Dynパケットは、コンテキストの静的部分および/または動的部分を通信するために使用されます。[RFC-3095]で定義されている各圧縮プロファイルについて、ヘッダーチェーンには、静的チェーンの終了を明確にマークする最後のヘッダーが1つあります。動的チェーンの長さは、IRヘッダー自体の静的チェーン、またはIR-Dynヘッダーのコンテキストの静的チェーンから推測されます。したがって、静的チェーンと動的チェーンの両方の長さは任意の長さであり、理論的には、任意の数のIPレベルでコンテキストを初期化する場合があります。
However, the general compressed header formats defined in [RFC-3095, section 5.7.] specifies that at most two levels of IP headers (the 'Inner' and the 'Outer' level of IP headers) may be included in a compressed header. Specifically, the format defined for Extension 3 [RFC-3095, section 5.7.5.] can only carry one single 'Outer' IP header. In addition, while list compression may be used to compress other types of headers, it cannot be used to compress additional IP headers, as IP headers may not be part of an extension header chain in compressed headers [RFC-3095, section 5.8.].
ただし、[RFC-3095、セクション5.7]で定義されている一般的な圧縮ヘッダー形式は、最大2つのレベルのIPヘッダー（「内側」と「外側」レベルのIPヘッダー）が圧縮ヘッダーに含まれることを指定しています。具体的には、拡張3 [RFC-3095、セクション5.7.5]に定義された形式は、1つの「外側」IPヘッダーのみを搭載できます。さらに、IPヘッダーは圧縮ヘッダー[RFC-3095、セクション5.8]のエクステンションヘッダーチェーンの一部ではない可能性があるため、他のタイプのヘッダーを圧縮するためにリスト圧縮を使用できますが、追加のIPヘッダーを圧縮することはできません。。
For the compression profiles defined in [RFC-3095], the consequence is that at most two levels of IP headers can be compressed. In other words, the presence of additional IP headers at best partially disables header compression, as the compressor will only be allowed to send IR and IR-DYN packets in such cases.
[RFC-3095]で定義されている圧縮プロファイルの場合、最大2つのレベルのIPヘッダーが圧縮される可能性があります。言い換えれば、コンプレッサーはそのような場合にはIRおよびIR-Dynパケットのみを送信できるため、せいぜい追加のIPヘッダーがヘッダー圧縮を部分的に無効にします。
For the compression of IP headers only, the additional IP headers would however not have to cause header compression to be disabled because there is no single packet type that ends the compressed chain. The excess IP headers could simply be left uncompressed by implicitly terminating the static and dynamic chains after at most two levels of IP headers.
ただし、IPヘッダーのみの圧縮では、追加のIPヘッダーは、圧縮チェーンを終了する単一のパケットタイプがないため、ヘッダー圧縮を無効にする必要はありません。過剰なIPヘッダーは、最大2レベルのIPヘッダーの後に静的および動的チェーンを暗黙的に終了することにより、単に圧縮されないままにすることができます。
The IP-only profile defined in this document goes one step further and supports compression of an arbitrary number of IP levels. This is achieved by adding a dynamic chain to the general format of compressed headers, to include the header part of each IP level in excess of the first two.
このドキュメントで定義されているIPのみのプロファイルは、さらに一歩進んでおり、任意の数のIPレベルの圧縮をサポートします。これは、圧縮ヘッダーの一般的な形式にダイナミックチェーンを追加して、各IPレベルのヘッダー部分を最初の2つ以上に含めることによって達成されます。
As explained above, the static chain within IR packets can be of arbitrary length, and the chain is terminated by the presence of a non-IP header (not IPinIP nor IPv6). Alternatively, the chain may be explicitly terminated with a special code value in the IP version field, as described in section 3.1. The dynamic chain is structured analogously.
上で説明したように、IRパケット内の静的チェーンは任意の長さである可能性があり、チェーンは非IPヘッダー（IPINIPまたはIPv6ではなく）の存在によって終了します。あるいは、セクション3.1で説明されているように、チェーンはIPバージョンフィールドの特別なコード値で明示的に終了する場合があります。動的チェーンは類似して構成されています。
For compressed headers, the information related to the initial two IP headers is carried as for the IP/UDP profile, and a chain of dynamic header information is added to the end of the compressed header for each and every additional IP header. Thus, this additional data structure is exactly the same as the one used in IR and IR-DYN packets. The length of the chain is inferred from the chain of static parameters in the context. While a dynamic chain carries dynamically changing parameters using an uncompressed representation, this ensures that flows with arbitrary levels of IP headers will not impair compression efficiency.
圧縮ヘッダーの場合、IP/UDPプロファイルのように最初の2つのIPヘッダーに関連する情報が掲載され、追加のすべてのIPヘッダーの圧縮ヘッダーの端に動的ヘッダー情報のチェーンが追加されます。したがって、この追加のデータ構造は、IRおよびIR-Dynパケットで使用されているものとまったく同じです。チェーンの長さは、コンテキストの静的パラメーターのチェーンから推測されます。動的チェーンは、圧縮されていない表現を使用して動的に変化するパラメーターを運びますが、これにより、任意のレベルのIPヘッダーを使用すると、圧縮効率が損なわれないことが保証されます。
Most IPv4 stacks assign an IP-ID according to the value of a counter, increasing by one for each outgoing packet. ROHC UDP compresses the IP-ID field using offset IP-ID encoding based on the UDP SN [RFC-3095]. For stacks generating IP-ID values using a pseudo-random number generator, the field is not compressed and is sent as-is in its entirety as additional octets after the compressed header.
ほとんどのIPv4スタックは、カウンターの値に従ってIP-IDを割り当て、発信パケットごとに1つ増加します。ROHC UDPは、UDP SN [RFC-3095]に基づいてオフセットIP-IDエンコードを使用してIP-IDフィールドを圧縮します。擬似ランダム数ジェネレーターを使用してIP-ID値を生成するスタックの場合、フィールドは圧縮されておらず、圧縮ヘッダーの後に追加のオクテットとしてそのまま送信されます。
Cases have also been found where an IPv4 stack uses a constant value for the IP Identifier. When the IP-ID field is constant, it cannot be compressed using offset IP-ID encoding and the field must be sent in its entirety. This overhead can be avoided with the addition of a flag within the dynamic part of the chain used to initialize the IPv4 header, as follow:
IPv4スタックがIP識別子に一定の値を使用する場合も発見されています。IP-IDフィールドが一定の場合、オフセットIP-IDエンコードを使用して圧縮することはできず、フィールドを完全に送信する必要があります。このオーバーヘッドは、次のように、IPv4ヘッダーの初期化に使用されるチェーンの動的部分内にフラグを追加することで回避できます。
Dynamic part:
動的部分：
+---+---+---+---+---+---+---+---+
| Type of Service |
+---+---+---+---+---+---+---+---+
| Time to Live |
+---+---+---+---+---+---+---+---+
/ Identification / 2 octets
+---+---+---+---+---+---+---+---+
| DF|RND|NBO|SID| 0 |
+---+---+---+---+---+---+---+---+
/ Generic extension header list / variable length
+---+---+---+---+---+---+---+---+
SID: Static IP Identifier.
SID：静的IP識別子。
For IR and IR-DYN packets, the logic is the same as for ROHC UDP with the addition that field(SID) must be kept in the context.
IRおよびIR-Dynパケットの場合、ロジックはROHC UDPの場合と同じです。フィールド（SID）をコンテキストに保持する必要があります。
For compressed headers other than IR and IR-DYN:
IRおよびIR-Dyn以外の圧縮ヘッダーの場合：
If value(RND) = 0 and context(SID) = 0, hdr(IP-ID) is compressed using Offset IP-ID encoding (see [RFC-3095 section 4.5.5]) using p = 0 and default-slope(IP-ID offset) = 0.
値（RND）= 0およびコンテキスト（SID）= 0の場合、HDR（IP-ID）がオフセットIP-IDエンコード（[RFC-3095セクション4.5.5]を参照）を使用して圧縮されます。IP-IDオフセット）= 0。
If value(RND) = 0 and context(SID) = 1, hdr(IP-ID) is constant and compressed away; hdr(IP-ID) is the value of context(IP-ID).
値（rnd）= 0およびcontext（sid）= 1の場合、HDR（IP-id）は一定で圧縮されます。HDR（IP-ID）はコンテキストの値（IP-ID）です。
If value(RND) = 1, IP-ID is the uncompressed hdr(IP-ID). IP-ID is then passed as additional octets at the end of the compressed header, after any extensions.
値（RND）= 1の場合、IP-IDは非圧縮HDR（IP-ID）です。次に、拡張機能の後、圧縮ヘッダーの最後に追加のオクテットとして渡されます。
Note: Only IR and IR-DYN packets can update context(SID).
注：IRおよびIR-Dynパケットのみがコンテキスト（SID）を更新できます。
Note: All other fields are the same as for ROHC UDP [RFC-3095].
注：他のすべてのフィールドは、ROHC UDP [RFC-3095]の場合と同じです。
The profiles defined in [RFC-3095] operate using different modes of compression. A mode transition can be requested once a packet has reached the decompressor by sending feedback indicating the desired mode. As per the specifications found in [RFC-3095], the compressor is compelled to honor such requests.
[RFC-3095]で定義されたプロファイルは、さまざまな圧縮モードを使用して動作します。目的のモードを示すフィードバックを送信することにより、パケットが減圧装置に到達したら、モードの遷移を要求できます。[RFC-3095]で見つかった仕様に従って、コンプレッサーはそのような要求を尊重することを余儀なくされています。
For the IP profile defined in this document, the Mode parameter for the value mode = 0 (packet types UOR-2, IR and IR-DYN) is redefined to allow the compressor to decline a mode transition requested by the decompressor:
このドキュメントで定義されているIPプロファイルの場合、値モード= 0（パケットタイプUOR-2、IR-DYN）のモードパラメーターが再定義され、コンプレッサーが減圧器が要求するモード遷移を拒否できるようにします。
Mode: Compression mode. 0 = (C)ancel Mode Transition
Upon receiving the Mode parameter set to '0', the decompressor MUST stay in its current mode of operation and SHOULD refrain from sending further mode transition requests for the declined mode for a certain amount of time.
モードパラメーターが「0」に設定されたモードパラメーターを受信すると、減圧装置は現在の動作モードにとどまる必要があり、減少モードのさらなるモード遷移要求を一定の時間送信することを控える必要があります。
More specifically, with reference to the parameters C_TRANS, C_MODE, D_TRANS, and D_MODE defined in [RFC-3095, section 5.6.1.], the following modifications apply when the compressor cancels a mode transition:
より具体的には、[RFC-3095、セクション5.6.1]で定義されているパラメーターC_TRANS、C_MODE、D_TRANS、およびD_MODEを参照して、コンプレッサーがモード遷移をキャンセルするときに次の変更が適用されます。
Parameters for the compressor side:
コンプレッサー側のパラメーター：
- C_MODE:
- c_mode：
This value must not be changed when sending mode information within packets if the mode parameter is set to '0' (as a response to a mode transition request from the decompressor).
モードパラメーターが「0」に設定されている場合、パケット内でモード情報を送信するときは、この値を変更してはなりません（減圧装置からのモード遷移要求への応答として）。
- C_TRANS:
- c_trans：
C_TRANS is (P)ending when receiving a mode transition request from the decompressor. C_TRANS is set to (D)one when the compressor receives an ACK for a UOR-2, IR-DYN, or IR packet sent with the mode parameter set to the mode in use at the time the mode transition request was initiated.
C_TRANSは（P）減圧器からモードトランジション要求を受信するときに終了します。C_TRANSは、モード遷移要求が開始された時点で使用中のモードに設定されたモードパラメーターで送信されたUOR-2、IR-Dyn、またはIRパケットのACKを受信したときに（d）1に設定されます。
Parameters for the decompressor side:
減圧器側のパラメーター：
- D_MODE:
- d_mode：
D_MODE MUST remain unchanged when receiving a UOR-2, an IR-DYN, or an IR packet sent with the mode parameter set to '0'.
D_Modeは、UOR-2、IR-Dyn、またはModeパラメーターを「0」に設定して送信されたIRパケットを受信する場合、変更されておく必要があります。
- D_TRANS:
- D_TRANS：
D_TRANS is (P)ending when a UOR-2, IR-DYN, or IR packet sent with the mode parameter set to '0' is received. It is set to (D)one when a packet of type 1 or 0 corresponding to the unchanged mode is received.
D_TRANSは、（P）モードパラメーター設定で「0」に設定されたモードパラメーターで送信されたUOR-2、IR-Dyn、またはIRパケットが受信されたときに終了します。変更されていないモードに対応するタイプ1または0のパケットが受信されると、（d）1に設定されます。
The resulting mode transition procedure is described below:
結果のモード遷移手順については、以下に説明します。
Compressor Decompressor
----------------------------------------------
C_MODE = X | | D_MODE = X
| Mode Request(Y) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = X | |
|->->->-+ IR/IR-DYN/UOR-2(SN,C) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_TRANS = P
|->-.. | D_MODE = X
| ACK(SN,X) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ X-0, X-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
| |
where X: mode in use before the mode transition was initiated Y: mode requested by the decompressor C: (C)ancel mode transition
ここで、x：モードモードが開始される前のモードy：減圧器Cによって要求されたモードc：（c）アンチェルモードの遷移
The static context for ROHC IP compression can be initialized in either of two ways:
ROHC IP圧縮の静的コンテキストは、2つの方法のいずれかで初期化できます。
1) By using an IR packet as in ROHC UDP, where the profile is 0x0004, and the static chain ends with the static part of an IP header, where the Next Header/Protocol field has any value but IPinIP (4) or IPv6 (41) [PROTOCOL], or where the IP version field indicates termination (see section 3.1). At the compressor, SN is initialized to a random value when the first IR packet is sent.
1) ROHC UDPのようにIRパケットを使用することにより、プロファイルは0x0004であり、静的チェーンはIPヘッダーの静的部分で終了します。ここでは、次のヘッダー/プロトコルフィールドにはIPINIP（4）またはIPv6（41）以外の値があります。[プロトコル]、またはIPバージョンフィールドが終了を示している場合（セクション3.1を参照）。コンプレッサーでは、最初のIRパケットが送信されると、SNはランダムな値に初期化されます。
2) By reusing an existing context. This is done with an IR-DYN packet, identifying profile 0x0004, where the dynamic chain corresponds to the prefix of the existing static chain, ending with an IP header where the Next Header/Protocol field has any value but IPinIP (4) or IPv6 (41) [PROTOCOL], or where the IP version field indicates termination (see section 3.1). At the compressor, SN is initialized to a random value when the first IR-DYN packet is sent.
2) 既存のコンテキストを再利用することにより。これは、IR-Dynパケットで行われ、プロファイル0x0004を識別します。動的チェーンは既存の静的チェーンのプレフィックスに対応し、次のヘッダー/プロトコルフィールドにIPINIP（4）またはIPv6以外の値があるIPヘッダーで終了します。（41）[プロトコル]、またはIPバージョンフィールドが終了を示している場合（セクション3.1を参照）。コンプレッサーでは、最初のIR-Dynパケットが送信されると、SNはランダムな値に初期化されます。
For ROHC IP, the dynamic part of an IR or IR-DYN packet is similar to the one for ROHC UDP, with a two-octet field containing the SN present at the end of the dynamic chain in IR and IR-DYN packets. It should be noted that the static and dynamic chains have an arbitrary length, and the SN is added only once, at the end of the dynamic chain in IR and IR-DYN packets.
ROHC IPの場合、IRまたはIR-Dynパケットの動的部分はROHC UDPの動的部分と類似しており、IRおよびIR-Dynパケットの動的チェーンの端にSNが存在するSNを含む2オクテットのフィールドがあります。静的チェーンと動的チェーンの長さは任意の長さであり、SNはIRおよびIR-Dynパケットのダイナミックチェーンの最後に1回だけ追加されることに注意する必要があります。
Except for one new feedback option (see section 3.7), the only packet format that differs from ROHC UDP is the general format for compressed packets, which has no UDP checksum in the end. Instead, it ends with a list of dynamic header portions, one for each IP header above the initial two (if any, as indicated by the presence of corresponding header portions in the static chain).
1つの新しいフィードバックオプション（セクション3.7を参照）を除き、ROHC UDPとは異なるパケット形式は、最終的にUDPチェックサムがない圧縮パケットの一般的な形式です。代わりに、最初の2つの上にある各IPヘッダーのダイナミックヘッダー部分のリストで終了します（staticチェーン内の対応するヘッダー部分の存在によって示されるように）。
The general format for a compressed header is thus as follows:
したがって、圧縮ヘッダーの一般的な形式は次のとおりです。
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : |
+---+---+---+---+---+---+---+---+ |
| first octet of base header | |
+---+---+---+---+---+---+---+---+ |
: : |
/ 0, 1, or 2 octets of CID / |
: : |
+---+---+---+---+---+---+---+---+ |
/ remainder of base header / |
+---+---+---+---+---+---+---+---+ |
: : |
/ Extension / |
: : |
--- --- --- --- --- --- --- --- |
: : |
+ IP-ID of outer IPv4 header +
: : (see section 5.7 of [RFC-3095])
--- --- --- --- --- --- --- ---
/ AH data for outer list / |
--- --- --- --- --- --- --- --- |
: : |
+ GRE checksum + |
: : |
--- --- --- --- --- --- --- --- |
: : |
+ IP-ID of inner IPv4 header + |
: : |
--- --- --- --- --- --- --- --- |
/ AH data for inner list / |
--- --- --- --- --- --- --- --- |
: : |
+ GRE checksum + |
: : |
--- --- --- --- --- --- --- ---
: List of :
/ Dynamic chains / variable, given by static chain
: for additional IP headers : (includes no SN)
--- --- --- --- --- --- --- ---
Note that the list of dynamic chains for the additional IP headers in compressed packets do not have a sequence number at the end of the chain, as SN is present within compressed base headers.
圧縮パケットの追加のIPヘッダーの動的チェーンのリストには、SNが圧縮ベースヘッダー内に存在するため、チェーンの端にシーケンス番号がないことに注意してください。
The CONTEXT_MEMORY option informs the compressor that the decompressor does not have sufficient memory resources to handle the context of the packet stream, as the stream is currently compressed.
Context_Memoryオプションは、ストリームが現在圧縮されているため、Packetストリームのコンテキストを処理するのに十分なメモリリソースがないことをコンプレッサーに通知します。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type = 9 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
When receiving a CONTEXT_MEMORY option, the compressor SHOULD take actions to compress the packet stream in a way that requires less decompressor memory resources, or stop compressing the packet stream.
Context_memoryオプションを受信する場合、コンプレッサーは、減圧器メモリリソースを必要とする方法でパケットストリームを圧縮するためのアクションを実行するか、パケットストリームの圧縮を停止する必要があります。
The security considerations of [RFC-3095] apply equally to this document, without exceptions or additions.
[RFC-3095]のセキュリティ上の考慮事項は、例外や追加なしに、このドキュメントに等しく適用されます。
ROHC profile identifier 0x0004 has been reserved by the IANA for the profile defined in this document.
ROHCプロファイル識別子0x0004は、このドキュメントで定義されているプロファイルのIANAによって予約されています。
The authors would like to thank Carsten Bormann, Fredrik Lindstrom, Tommy Lundemo, and especially the committed document reviewers Kristofer Sandlund and Mark West, for valuable input and review.
著者は、貴重な入力とレビューについて、Carsten Bormann、Fredrik Lindstrom、Tommy Lundemo、特にコミットされた文書レビュー担当者のKristofer SandlundとMark Westに感謝したいと思います。
[RFC-791] Postel, J., "Internet Protocol", RFC 791, September 1981.
[RFC-791] Postel、J。、「インターネットプロトコル」、RFC 791、1981年9月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC-2460] Deering、S。and R. Hinden、「Internet Protocol、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC-3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "Robust Header Compression (ROHC)", RFC 3095, July 2001.
[RFC-3095] Bormann、C.、Burmeister、C.、Degermark、M.、Fukushima、H.、Hannu、H.、Jonsson、L-e。、Hakenberg、R.、Koren、T.、Le、K。、Liu、Z.、Martensson、A.、Miyazaki、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T。、およびH. Zheng、「堅牢なヘッダー圧縮（ROHC）」、RFC 3095、2001年7月。
[PROTOCOL] "Assigned Internet Protocol Numbers", IANA registry at: http://www.iana.org/assignments/protocol-numbers
[プロトコル]「インターネットプロトコル番号の割り当て」、IANAレジストリ：http：//www.iana.org/assignments/protocol-numbers
The profiles defined in [RFC-3095] operate using different modes of compression: Unidirectional (U-Mode), Bi-directional Optimistic (O-Mode), and Bi-directional Reliable (R-Mode). Compression always starts in the U-Mode, and mode transitions can only be initiated by the decompressor [RFC-3095, section 5.6.]. A mode transition can be requested once a packet has reached the decompressor by sending feedback indicating the desired mode.
[RFC-3095]で定義されたプロファイルは、異なるモードの圧縮モードを使用して動作します：一方向（Uモード）、双方向の楽観的（Oモード）、および双方向信頼性（Rモード）。圧縮は常にUモードで始まり、モード遷移は減圧器[RFC-3095、セクション5.6]によってのみ開始できます。目的のモードを示すフィードバックを送信することにより、パケットが減圧装置に到達したら、モードの遷移を要求できます。
With reference to the parameters C_TRANS, C_MODE, D_TRANS, and D_MODE defined in [RFC-3095, section 5.6.1.], the following sub-sections describe the resulting procedures when a compressor declines a mode transition request from the decompressor as described in section 3.4.
[RFC-3095、セクション5.6.1。]で定義されているパラメーターC_TRANS、C_MODE、D_TRANS、およびD_MODEを参照して、次のサブセクションは、コンプレッサーが説明したように分解器からのモード遷移要求を拒否する場合の結果の手順を説明します。セクション3.4。
When the decompressor initiates a mode transition from Optimistic to Reliable mode, the cancellation of the transition procedure is as follows:
減圧器が楽観的なモードから信頼できるモードへのモード遷移を開始すると、遷移手順のキャンセルは次のとおりです。
Compressor Decompressor
----------------------------------------------
| |
| ACK(R)/NACK(R) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = O | |
|->->->-+ IR/IR-DYN/UOR-2(SN,C) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_TRANS = P
|->-.. | D_MODE = O
| ACK(SN,O) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
The compressor must not send packet types 1 or 0 when C_TRANS is P, i.e., not until it has received an ACK for a UOR-2, IR-DYN, or IR packet sent with the mode transition parameter set to C. When the decompressor receives a UOR-2, IR-DYN, or IR packet sent with the mode transition parameter set to C, it must keep the value D_MODE as O and set D_TRANS to P. When the decompressor receives packet types 0 or 1, after having ACKed a UOR-2, IR-DYN, or IR packet, it sets D_TRANS to D.
コンプレッサーは、C_TRANSがPの場合、パケットタイプ1または0を送信してはなりません。つまり、Mode TransitionパラメーターがCに設定されたUOR-2、IR-Dyn、またはIRパケットのACKを受信するまでは、Decompressorを設定したときにモードトランジションパラメーターをCに設定して送信されたUOR-2、IR-Dyn、またはIRパケットを受信すると、d_modeをoとしてd_modeに保ち、d_transをPに設定する必要があります。UOR-2、IR-Dyn、またはIRパケット、D_TransをDに設定します。
The cancellation of a transition from Unidirectional to Reliable mode follows the same procedure as defined in section 4.2 above.
単方向から信頼できるモードへの遷移のキャンセルは、上記のセクション4.2で定義されているのと同じ手順に従います。
When the decompressor initiates a mode transition from Reliable to Optimistic mode, the cancellation of the transition procedure is described as follows:
減圧器が信頼性から楽観的モードへのモード遷移を開始すると、遷移手順のキャンセルは次のように説明されています。
Compressor Decompressor
----------------------------------------------
| |
| ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = R | |
|->->->-+ IR/IR-DYN/UOR-2(SN,C) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_MODE = R
|->-.. |
| ACK(SN,R) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ R-0, R-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
| |
The compressor must not send packet types 1 or 0 when C_TRANS is P, i.e., not until it has received an ACK for a UOR-2, IR-DYN, or IR packet sent with the mode transition parameter set to C. When the decompressor receives a UOR-2, IR-DYN, or IR packet sent with the mode transition parameter set to C, it must keep the value D_MODE as R. When the decompressor receives packet types 0 or 1, after having ACKed a UOR-2, IR-DYN, or IR packet, it sets D_TRANS to D.
コンプレッサーは、C_TRANSがPの場合、パケットタイプ1または0を送信してはなりません。つまり、Mode TransitionパラメーターがCに設定されたUOR-2、IR-Dyn、またはIRパケットのACKを受信するまでは、Decompressorを設定したときにモードトランジションパラメーターをCに設定して送信されたUOR-2、IR-Dyn、またはIRパケットを受信します。D_MODEをRとして値D_Modeに保持する必要があります。IR-Dyn、またはIRパケット、D_TransをDに設定します
When the decompressor initiates a mode transition from Reliable or Optimistic mode back to Unidirectional mode, the cancellation of the transition procedure is as follows:
減圧装置が信頼性または楽観的なモードから単方向モードに戻るモード遷移を開始すると、遷移手順のキャンセルは次のとおりです。
Compressor Decompressor
----------------------------------------------
| |
| ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = O/R| |
|->->->-+ IR/IR-DYN/UOR-2(SN,C) |
| +->->->->->->->-+ |
|->-.. +->->->-|
|->-.. |
| ACK(SN,O/R) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| R-0, R-1* or |
|->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
D_MODE = O/R
When the decompressor receives a UOR-2, IR-DYN, or IR packet sent with the mode transition parameter set to C, it must keep the value D_MODE to the bi-directional mode already in use (either O- or R-mode). After ACKing the first UOR-2(C), IR-DYN(C), or IR(C), the decompressor MUST continue to send feedback with the Mode parameter set to the bi-directional mode in use (either O- or R-mode) until it receives packet types 0 or 1. When the decompressor receives packet types 0 or 1, after having ACKed a UOR-2, IR-DYN, or IR packet, it sets D_TRANS to D.
減圧器がcに設定されたモードトランジションパラメーターで送信されたUOR-2、IR-Dyn、またはIRパケットを受信する場合、既に使用中の双方向モード（O-またはR-Mode）に値d_modeを保持する必要があります。。最初のUOR-2（c）、Ir-Dyn（c）、またはIR（c）をアクセスした後、減圧器は使用中の双方向モードに設定されたモードパラメーターを使用してフィードバックを引き続き送信する必要があります（O-またはRのいずれかです。-Mode）パケットタイプ0または1を受信するまで、減圧器がパケットタイプ0または1を受信したとき、UOR-2、IR-Dyn、またはIRパケットをAckした後、D_TransをDに設定します。
Authors' Addresses
著者のアドレス
Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea, Sweden
Lars-erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea、Sweden
Phone: +46 8 404 29 61
Fax: +46 920 996 21
EMail: lars-erik.jonsson@ericsson.com
Ghyslain Pelletier Ericsson AB Box 920 SE-971 28 Lulea, Sweden
Ghyslain Pelletier Ericsson AB Box 920 SE-971 28 Lulea、Sweden
Phone: +46 8 404 29 43
Fax: +46 920 996 21
EMail: ghyslain.pelletier@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。