Network Working Group G. Pelletier
Request for Comments: 4019 Ericsson AB
Category: Standards Track April 2005
RObust Header Compression (ROHC):
Profiles for User Datagram Protocol (UDP) Lite
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.
このドキュメントでは、インターネットコミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めています。 このプロトコルの標準化状態とステータスについては、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。 このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document defines Robust Header Compression (ROHC) profiles for compression of Real-Time Transport Protocol, User Datagram Protocol-Lite, and Internet Protocol (RTP/UDP-Lite/IP) packets and UDP-Lite/IP. These profiles are defined based on their differences with the profiles for UDP as specified in RFC 3095.
このドキュメントでは、リアルタイムトランスポートプロトコル、ユーザーデータグラムプロトコルライト、およびインターネットプロトコル（RTP / UDP-Lite / IP）パケットとUDP-Lite / IPの圧縮用の堅牢なヘッダー圧縮（ROHC）プロファイルを定義します。 これらのプロファイルは、RFC 3095で指定されているUDPのプロファイルとの違いに基づいて定義されます。
Table of Contents
目次
1. Introduction.................................................. 2
2. Terminology................................................... 3
3. Background.................................................... 3
3.1. Overview of the UDP-Lite Protocol....................... 3
3.2. Expected Behaviours of UDP-Lite Flows................... 5
3.2.1. Per-Packet Behavior............................. 5
3.2.2. Inter-Packet Behavior........................... 5
3.2.3. Per-Flow Behavior............................... 5
3.3. Header Field Classification............................. 5
4. Rationale behind the Design of ROHC Profiles for UDP-Lite..... 6
4.1. Design Motivations...................................... 6
4.2. ROHC Considerations..................................... 6
5. ROHC Profiles for UDP-Lite.................................... 6
5.1. Context Parameters...................................... 7
5.2. Initialization.......................................... 8
5.2.1. Initialization of the UDP-Lite Header [1]....... 8
5.2.2. Compressor and Decompressor Logic............... 9
5.3. Packet Formats.......................................... 9
5.3.1. General Packet Format........................... 9
5.3.2. Packet Type CCE: CCE(), CCE(ON), and CCE(OFF)... 10
5.3.2.1. Properties of CCE():.................. 11
5.3.2.2. Properties of CCE(ON):................ 11
5.3.2.3. Properties of CCE(OFF):............... 12
5.4. Compressor Logic........................................ 12
5.5. Decompressor Logic...................................... 12
5.6. Additional Mode Transition Logic........................ 13
5.7. The CONTEXT_MEMORY Feedback Option...................... 13
5.8. Constant IP-ID.......................................... 13
6. Security Considerations....................................... 14
7. IANA Considerations........................................... 14
8. Acknowledgments............................................... 15
9. References.................................................... 15
9.1. Normative References.................................... 15
9.2. Informative References.................................. 15
Appendix A. Detailed Classification of Header Fields............. 17
Appendix B. Detailed Format of the CCE Packet Type............... 20
Author's Address.................................................. 22
Full Copyright Statement.......................................... 23
The ROHC WG has developed a header compression framework on top of which various profiles can be defined for different protocol sets or compression strategies. Due to the demands of the cellular industry for an efficient way to transport voice over IP over wireless, ROHC [2] has mainly focused on compression of IP/UDP/RTP headers, which are generous in size, especially compared to the payloads often carried by packets with these headers.
ROHC WGはヘッダー圧縮フレームワークを開発し、その上でさまざまなプロトコルセットまたは圧縮戦略に対してさまざまなプロファイルを定義できます。 IPを介してワイヤレスで音声を転送する効率的な方法に対する携帯電話業界の要求により、ROHC [2]は主にIP / UDP / RTPヘッダーの圧縮に重点を置いています。 これらのヘッダーを持つパケットによって。
ROHC RTP has become a very efficient, robust, and capable compression scheme, able to compress the headers down to a total size of one octet only. Also, transparency is guaranteed to an extremely high extent, even when residual bit errors are present in compressed headers delivered to the decompressor.
ROHC RTPは、ヘッダーを合計サイズが1オクテットのみにまで圧縮できる、非常に効率的で堅牢な機能を備えた圧縮方式になりました。 また、圧縮解除ヘッダーに配信される圧縮ヘッダーに残留ビットエラーが存在する場合でも、透過性は非常に高い範囲で保証されます。
UDP-Lite [4] is a transport protocol similar to the UDP protocol [7]. UDP-Lite is useful for applications designed with the capability to tolerate errors in the payload, for which receiving damaged data is better than dealing with the loss of entire packets. This may be particularly suitable when packets are transported over link technologies in which data can be partially damaged, such as wireless links.
UDP-Lite [4]は、UDPプロトコル[7]に類似したトランスポートプロトコルです。 UDP-Liteは、ペイロード内のエラーを許容する機能を備えて設計されたアプリケーションに役立ちます。破損したデータの受信は、パケット全体の損失を処理するよりも優れています。 これは、無線リンクなど、データが部分的に破損する可能性のあるリンクテクノロジーを介してパケットが転送される場合に特に適しています。
Although these transport protocols are very similar, ROHC profiles must be defined separately for robust compression of UDP-Lite headers because UDP-Lite does not share the same protocol identifier with UDP. Also, the UDP-Lite Checksum Coverage field does not share the semantics of the corresponding UDP Length field, and as a consequence it cannot always be inferred anymore.
これらのトランスポートプロトコルは非常に似ていますが、UDP-LiteはUDPと同じプロトコル識別子を共有しないため、UDP-Liteヘッダーの堅牢な圧縮のためにROHCプロファイルを個別に定義する必要があります。 また、UDP-Liteチェックサムカバレッジフィールドは、対応するUDP長さフィールドのセマンティクスを共有しないため、結果として常に推測できるとは限りません。
This document defines two ROHC profiles for efficient compression of UDP-Lite headers. The objective of this document is to provide simple modifications to the corresponding ROHC profiles for UDP, specified in RFC 3095 [2]. In addition, the ROHC profiles for UDP-Lite support some of the mechanisms defined in the profile for compression of IP headers [3] (ROHC IP-Only). This specification includes support for compression of multiple IP headers and for compressing IP-ID fields with constant behavior, as well as improved mode transition logic and a feedback option for decompressors with limited memory resources.
このドキュメントでは、UDP-Liteヘッダーの効率的な圧縮のために2つのROHCプロファイルを定義しています。 このドキュメントの目的は、RFC 3095 [2]で指定されているUDPの対応するROHCプロファイルに簡単な変更を加えることです。 さらに、UDP-LiteのROHCプロファイルは、IPヘッダーの圧縮プロファイルで定義されているメカニズムのいくつかをサポートしています[3]（ROHC IPのみ）。 この仕様には、複数のIPヘッダーの圧縮、および一定の動作でのIP-IDフィールドの圧縮のサポート、および改良されたモード移行ロジックと、限られたメモリリソースを持つ圧縮解除プログラムのフィードバックオプションが含まれます。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD, "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1].
このドキュメントでは、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD、SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は RFC 2119 [1]で説明されているように解釈されます。
ROHC RTP : RTP/UDP/IP profile 0x0001 defined in RFC 3095 [2]. ROHC UDP : UDP/IP profile 0x0002 defined in RFC 3095 [2]. ROHC UDP-Lite : UDP-Lite/IP profile defined in this document. ROHC RTP/UDP-Lite: RTP/UDP-Lite/IP profile defined in this document.
ROHC RTP：RFC 3095 [2]で定義されているRTP / UDP / IPプロファイル0x0001。 ROHC UDP：RFC 3095 [2]で定義されているUDP / IPプロファイル0x0002。 ROHC UDP-Lite：このドキュメントで定義されているUDP-Lite / IPプロファイル。 ROHC RTP / UDP-Lite：このドキュメントで定義されているRTP / UDP-Lite / IPプロファイル。
UDP-Lite is a transport protocol defined as an independent variant of the UDP transport protocol. UDP-Lite is very similar to UDP, and it allows applications that can tolerate errors in the payload to use a checksum with an optional partial coverage. This is particularly useful with IPv6 [6], in which the use of the transport-layer checksum is mandatory.
UDP-Liteは、UDPトランスポートプロトコルの独立したバリアントとして定義されているトランスポートプロトコルです。 UDP-LiteはUDPに非常に似ており、ペイロードのエラーを許容できるアプリケーションが、オプションの部分カバレッジでチェックサムを使用できるようにします。 これは、トランスポート層チェックサムの使用が必須であるIPv6 [6]で特に役立ちます。
UDP-Lite replaces the Length field of the UDP header with a Checksum Coverage field. This field indicates the number of octets covered by the 16-bit checksum, which is applied on a per-packet basis. The coverage area always includes the UDP-Lite header and may cover the entire packet, in which case UDP-Lite becomes semantically identical to UDP. UDP-Lite and UDP do not share the same protocol identifier.
UDP-Liteは、UDPヘッダーの長さフィールドをチェックサムカバレッジフィールドに置き換えます。 このフィールドは、パケットごとに適用される16ビットチェックサムでカバーされるオクテットの数を示します。 カバレッジエリアには常にUDP-Liteヘッダーが含まれ、パケット全体をカバーする場合があります。この場合、UDP-Liteは意味的にUDPと同一になります。 UDP-LiteとUDPは同じプロトコル識別子を共有しません。
The UDP-Lite header format:
UDP-Liteヘッダー形式：
0 15 16 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| Checksum | |
| Coverage | Checksum |
+--------+--------+--------+--------+
| |
: Payload :
| |
+-----------------------------------+
Like the UDP checksum, the UDP-Lite checksum is an end-to-end mechanism against erroneous delivery of error sensitive data. This checksum is mandatory with IPv6 [5] for both protocols. However, unlike its UDP counterpart, the UDP-Lite checksum may not be transmitted as all zeroes and cannot be disabled for IPv4 [5]. For UDP, if the checksum is disabled (IPv4 only), the Checksum field maintains a constant value and is normally not sent by the header compression scheme. If the UDP checksum is enabled (mandatory for IPv6), such an unpredictable field cannot be compressed and is sent uncompressed. The UDP Length field, however, is always redundant and can be provided by the IP module. Header compression schemes do not normally transmit any bits of information for this field, as its value can be inferred from the link layer.
UDPチェックサムと同様に、UDP-Liteチェックサムは、エラーに敏感なデータの誤った配信に対するエンドツーエンドのメカニズムです。 このチェックサムは、両方のプロトコルのIPv6 [5]で必須です。 ただし、UDPとは異なり、UDP-Liteチェックサムはすべてゼロとして送信されない場合があり、IPv4に対して無効にすることはできません[5]。 UDPの場合、チェックサムが無効になっている場合（IPv4のみ）、チェックサムフィールドは一定の値を維持し、通常はヘッダー圧縮スキームによって送信されません。 UDPチェックサムが有効になっている場合（IPv6に必須）、そのような予測不能なフィールドは圧縮できず、圧縮されずに送信されます。 ただし、UDP長フィールドは常に冗長であり、IPモジュールで提供できます。 通常、ヘッダー圧縮方式はこのフィールドの情報ビットを送信しません。その値はリンク層から推測できるためです。
For UDP-Lite, the checksum also has unpredictable values, and this field must always be included as-is in the compressed header for both IPv4 and IPv6. Furthermore, as the UDP Length field is redefined as the Checksum Coverage field by UDP-Lite, this leads to different properties for this field from a header-compression perspective.
UDP-Liteの場合、チェックサムにも予測不可能な値があり、このフィールドは常にIPv4とIPv6の両方の圧縮ヘッダーにそのまま含める必要があります。 さらに、UDP長さフィールドはUDP-Liteによってチェックサムカバレッジフィールドとして再定義されるため、ヘッダー圧縮の観点からこのフィールドのさまざまなプロパティにつながります。
The following summarizes the relationship between UDP and UDP-Lite:
以下に、UDPとUDP-Liteの関係をまとめます。
- UDP-Lite and UDP have different protocol identifiers. - The UDP-Lite checksum cannot be disabled for IPv4. - UDP-Lite redefines the UDP Length field as the Checksum Coverage field, with different semantics. - UDP-Lite is semantically equivalent to UDP when the Checksum Coverage field indicates the total length of the packet.
-UDP-LiteとUDPには異なるプロトコル識別子があります。 -UDP-LiteチェックサムはIPv4に対して無効にできません。 -UDP-Liteは、異なるセマンティクスでUDP長フィールドをチェックサムカバレッジフィールドとして再定義します。 -チェックサムカバレッジフィールドがパケットの全長を示す場合、UDP-Liteはセマンティック上UDPと同等です。
The next section provides a more detailed discussion of the behavior of the Checksum Coverage field of UDP-Lite in relation to header compression.
次のセクションでは、ヘッダー圧縮に関連するUDP-Liteのチェックサムカバレッジフィールドの動作の詳細について説明します。
As mentioned in the previous section, the checksum coverage value is applied independently of other packets that may belong to the same flow. Specifically, the value of the checksum coverage may indicate that the UDP-Lite packet is either entirely covered by the checksum or covered up to some boundary less than the packet size but including the UDP-Lite header.
前のセクションで述べたように、チェックサムカバレッジ値は、同じフローに属する他のパケットとは無関係に適用されます。 具体的には、チェックサムカバレッジの値は、UDP-Liteパケットがチェックサムで完全にカバーされているか、パケットサイズよりも小さいがUDP-Liteヘッダーを含む境界までカバーされていることを示します。
In relation to each other, UDP-Lite packets may exhibit one of three possible change patterns, where within a sequence of packets the value of the Checksum Coverage field is
互いに関連して、UDP-Liteパケットは、パケットのシーケンス内でチェックサムカバレッジフィールドの値が
1. changing, while covering the entire packet; 2. unchanging, covering up to a fixed boundary within the packet; or 3. changing, but it does not follow any specific pattern.
1.パケット全体をカバーしながら変更します。 2.変化せず、パケット内の固定境界までカバーします。 または3.変化するが、特定のパターンに従っていない。
The first pattern above corresponds to the semantics of UDP, when the UDP checksum is enabled. For this case, the checksum coverage field varies according to the packet length and may be inferred from the IP header, as is the UDP Length field value.
上記の最初のパターンは、UDPチェックサムが有効な場合のUDPのセマンティクスに対応しています。 この場合、チェックサムカバレッジフィールドは、パケット長に応じて変化し、UDP長フィールド値と同様に、IPヘッダーから推測できます。
The second pattern corresponds to the case where the coverage is the same from one packet to another within a particular sequence. For this case, the Checksum Coverage field may be a static value defined in the context, and it does not have to be sent in the compressed header. For the third case, no useful change pattern can be identified from packet to packet for the value of the checksum coverage field, and it must be included in the compressed header.
2番目のパターンは、特定のシーケンス内でパケットごとにカバレッジが同じ場合に対応します。 この場合、チェックサムカバレッジフィールドはコンテキストで定義された静的な値である可能性があり、圧縮ヘッダーで送信する必要はありません。 3番目のケースでは、チェックサムカバレッジフィールドの値に対して、パケットごとに有用な変更パターンを識別できず、圧縮ヘッダーに含める必要があります。
It can be expected that any one of the above change patterns for sequences of packets may be predominant at any time during the lifetime of the UDP-Lite flow. A flow that predominantly follows the first two change patterns described above may provide opportunities for compressing the Checksum Coverage field for most of the packets.
パケットのシーケンスの上記の変更パターンのいずれかが、UDP-Liteフローの存続期間中はいつでも支配的であることが予想されます。 主に上記の最初の2つの変更パターンに従うフローは、ほとんどのパケットのチェックサムカバレッジフィールドを圧縮する機会を提供します。
In relation to the header field classification of RFC 3095 [2], the first two patterns represent the case where the value of the Checksum Coverage field behavior is fixed and may be either INFERRED (pattern
RFC 3095 [2]のヘッダーフィールド分類に関連して、最初の2つのパターンは、チェックサムカバレッジフィールドの動作の値が固定され、INFERRED（pattern
1) or STATIC (pattern 2). Pattern 3 is for the case where the value varies unpredictably, the field is CHANGING, and the value must be sent along with every packet.
1）またはSTATIC（パターン2）。 パターン3は、値が予測不能に変化し、フィールドが変更され、すべてのパケットとともに値を送信する必要がある場合です。
Additional information regarding the analysis of the behavior of the UDP-Lite fields may be found in Appendix A.
UDP-Liteフィールドの動作の分析に関する追加情報は、付録Aに記載されています。
Simplicity is a strong motivation for the design of the UDP-Lite header compression profiles. The profiles defined for UDP-Lite should entail only a few simple modifications to the corresponding profiles defined for UDP in RFC 3095 [2]. In addition, it is desirable to include some of the improvements found in the ROHC IP-Only profile [3]. Finally, whenever UDP-Lite is used in a manner that is semantically identical to UDP, the compression efficiency should be similar.
シンプルさは、UDP-Liteヘッダー圧縮プロファイルの設計の強力な動機です。 UDP-Liteに定義されたプロファイルは、RFC 3095 [2]でUDPに定義された対応するプロファイルへのいくつかの簡単な変更のみを必要とします。 さらに、ROHC IP-Onlyプロファイル[3]に見られるいくつかの改善点を含めることが望ましいです。 最後に、UDP-LiteがUDPと意味的に同一の方法で使用されるときはいつでも、圧縮効率は似ているはずです。
The simplest approach to the definition of ROHC profiles for UDP-Lite is to treat the Checksum Coverage field as an irregular value, and to send it uncompressed for every packet. This may be achieved simply by adding the field to the definition of the general packet format [2]. However, then the compression efficiency would always be less than for UDP.
UDP-LiteのROHCプロファイルを定義する最も簡単な方法は、チェックサムカバレッジフィールドを不規則な値として扱い、すべてのパケットに対して非圧縮で送信することです。 これは、一般的なパケット形式の定義にフィールドを追加するだけで実現できます[2]。 ただし、圧縮効率は常にUDPの場合よりも低くなります。
Some care should be given to achieve compression efficiency for UDP-Lite similar to that for UDP when the Checksum Coverage field behaves like the UDP Length field. This requires the possibility to infer the Checksum Coverage field when it is equal to the length of the packet. Otherwise, this would put the UDP-Lite protocol at a disadvantage over links where header compression is used, when its behavior is made similar to the semantics of UDP.
Checksum CoverageフィールドがUDP Lengthフィールドのように動作する場合、UDP-Liteの圧縮効率をUDPの圧縮効率と同様にするために、ある程度の注意を払う必要があります。 これには、パケットの長さと等しい場合、チェックサムカバレッジフィールドを推測する可能性が必要です。 そうしないと、UDP-Liteプロトコルの動作がUDPのセマンティクスと同様になると、ヘッダー圧縮が使用されるリンクよりも不利になります。
A mechanism to detect the presence of the Checksum Coverage field in compressed headers is thus needed. This is achieved by defining a new packet type with the identifiers left unused in RFC 3095 [2].
そのため、圧縮ヘッダー内のチェックサムカバレッジフィールドの存在を検出するメカニズムが必要です。 これは、RFC 3095 [2]で未使用の識別子を使用して新しいパケットタイプを定義することで実現されます。
This section defines two ROHC profiles:
このセクションでは、2つのROHCプロファイルを定義します。
- RTP/UDP-Lite/IP compression (profile 0x0007) - UDP-Lite/IP compression (profile 0x0008)
-RTP / UDP-Lite / IP圧縮（プロファイル0x0007）-UDP-Lite / IP圧縮（プロファイル0x0008）
These profiles build on the specifications found in RFC 3095 [2], with as little modification as possible. Unless it is explicitly stated otherwise, the profiles defined herein follow the specifications of ROHC UDP and ROHC RTP, respectively.
これらのプロファイルは、RFC 3095 [2]に記載されている仕様に基づいて構築されており、可能な限り変更はほとんどありません。 特に明記されていない限り、ここで定義されているプロファイルは、それぞれROHC UDPおよびROHC RTPの仕様に従います。
Note also that this document reuses the notation found in [2].
また、このドキュメントは[2]にある表記を再利用することに注意してください。
As described in [2], information about previous packets is maintained in a context. This includes information describing the packet stream and compression parameters. Although the UDP and UDP-Lite protocols share many commonalities, the differences in semantics as described earlier render the following parameter inapplicable:
[2]で説明されているように、以前のパケットに関する情報はコンテキストで維持されます。 これには、パケットストリームと圧縮パラメータを説明する情報が含まれます。 UDPおよびUDP-Liteプロトコルには多くの共通点がありますが、前述のセマンティクスの違いにより、次のパラメーターは適用できません。
The parameter context(UDP Checksum)
パラメーターコンテキスト（UDPチェックサム）
The UDP-Lite checksum cannot be disabled, as opposed to UDP. The parameter context(UDP Checksum) defined in [2] (section 5.7) is therefore not used for compression of UDP-Lite.
UDPとは異なり、UDP-Liteチェックサムを無効にすることはできません。 したがって、[2]（セクション5.7）で定義されているパラメーターコンテキスト（UDPチェックサム）は、UDP-Liteの圧縮には使用されません。
In addition, the UDP-Lite checksum is always sent as-is in every compressed packet. However, the Checksum Coverage field may not always be sent in each compressed packet, and the following context parameter is used to indicate whether the field is sent:
さらに、UDP-Liteチェックサムは、すべての圧縮パケットで常にそのまま送信されます。 ただし、チェックサムカバレッジフィールドは各圧縮パケットで常に送信されるとは限らず、次のコンテキストパラメータを使用して、フィールドが送信されるかどうかを示します。
The parameter context(UDP-Lite Coverage Field Present)
パラメータコンテキスト（UDP-Lite Coverage Field Present）
Whether the UDP-Lite Checksum Coverage field is present or not in the general packet format (see section 5.3.1) is controlled by the value of the Coverage Field Present (CFP) flag in the context.
UDP-Lite Checksum Coverageフィールドが一般的なパケット形式（セクション5.3.1を参照）に存在するかどうかは、コンテキストのCoverage Field Present（CFP）フラグの値によって制御されます。
If context(CFP) is nonzero, the Checksum Coverage field is not compressed, and it is present within compressed packets. If context(CFP) is zero, the Checksum Coverage field is compressed, and it is not sent. This is the case when the value of the Checksum Coverage field follows a stable inter-packet change pattern; the field has either a constant value or it has a value equal to the packet length for most packets in a sequence (see section 3.2).
context（CFP）がゼロ以外の場合、チェックサムカバレッジフィールドは圧縮されず、圧縮パケット内に存在します。 context（CFP）がゼロの場合、チェックサムカバレッジフィールドは圧縮され、送信されません。 これは、チェックサムカバレッジフィールドの値が安定したパケット間変更パターンに従う場合です。 フィールドには定数値があるか、シーケンス内のほとんどのパケットのパケット長に等しい値があります（セクション3.2を参照）。
Finally, the following context parameter is needed to indicate whether the field should be inferred or taken from a value previously saved in the context:
最後に、コンテキストに以前に保存された値からフィールドを推測するか取得するかを示すために、次のコンテキストパラメータが必要です。
The parameter context(UDP-Lite Coverage Field Inferred)
パラメーターコンテキスト（UDP-Lite Coverage Field Inferred）
When the UDP-Lite Checksum Coverage field is not present in the compressed header (CFP=0), whether it is inferred is controlled by the value of the Coverage Field Inferred (CFI) flag in the context.
UDP-Liteチェックサムカバレッジフィールドが圧縮ヘッダーに存在しない場合（CFP = 0）、推論されるかどうかは、コンテキストのCoverage Field Inferred（CFI）フラグの値によって制御されます。
If context(CFI) is nonzero, the Checksum Coverage field is inferred from the packet length, similarly as for the UDP Length field in ROHC RTP. If context(CFI) is zero, the Checksum Coverage field is decompressed by using context(UDP-Lite Checksum Coverage). Therefore, when context(CFI) is updated to a nonzero value, the value of the Checksum Coverage field stored in the context must also be updated.
context（CFI）がゼロ以外の場合、ROHC RTPのUDP Lengthフィールドと同様に、Checksum Coverageフィールドはパケット長から推測されます。 context（CFI）がゼロの場合、checksum Coverageフィールドはcontext（UDP-Lite Checksum Coverage）を使用して圧縮解除されます。 したがって、context（CFI）がゼロ以外の値に更新されると、コンテキストに保存されているChecksum Coverageフィールドの値も更新する必要があります。
Unless it is stated otherwise, the mechanisms of ROHC RTP and ROHC UDP found in [2] are used also for the ROHC RTP/UDP-Lite and the ROHC UDP-Lite profiles, respectively.
特に明記しない限り、[2]にあるROHC RTPおよびROHC UDPのメカニズムは、それぞれROHC RTP / UDP-LiteおよびROHC UDP-Liteプロファイルにも使用されます。
In particular, the considerations of ROHC UDP regarding the UDP SN taking the role of the RTP Sequence Number apply to ROHC UDP-Lite. Also, the static context for ROHC UDP-Lite may be initialized by reusing an existing context belonging to a stream compressed by using ROHC RTP/UDP-Lite (profile 0x0007), similarly as for ROHC UDP.
特に、RTPシーケンス番号の役割をとるUDP SNに関するROHC UDPの考慮事項は、ROHC UDP-Liteに適用されます。 また、ROHC UDPの場合と同様に、ROHC RTP / UDP-Lite（プロファイル0x0007）を使用して圧縮されたストリームに属する既存のコンテキストを再利用することにより、ROHC UDP-Liteの静的コンテキストを初期化できます。
The structure of the IR and IR-DYN packets and the initialization procedures are the same as for the ROHC profiles for UDP [2], with the exception of the dynamic part as specified for UDP. A 2-octet field containing the checksum coverage is added before the Checksum field. This affects the format of dynamic chains in both IR and IR-DYN packets.
IRおよびIR-DYNパケットの構造と初期化手順は、UDP [2]のROHCプロファイルと同じです。ただし、UDPに指定されている動的部分は例外です。 チェックサムカバレッジを含む2オクテットフィールドは、チェックサムフィールドの前に追加されます。 これは、IRパケットとIR-DYNパケットの両方の動的チェーンの形式に影響します。
Dynamic part:
動的部分：
+---+---+---+---+---+---+---+---+
/ Checksum Coverage / 2 octets
+---+---+---+---+---+---+---+---+
/ Checksum / 2 octets
+---+---+---+---+---+---+---+---+
CRC-DYNAMIC: Checksum Coverage field, Checksum field (octets 5 - 8).
CRC-DYNAMIC：チェックサムカバレッジフィールド、チェックサムフィールド（オクテット5-8）。
CRC-STATIC: All other fields (octets 1 - 4).
CRC-STATIC：他のすべてのフィールド（オクテット1〜4）。
The following logic must be used by both the compressor and the decompressor for assigning values to the parameters context(CFP) and context(CFI) during initialization:
初期化中にパラメータcontext（CFP）およびcontext（CFI）に値を割り当てるには、コンプレッサーとデコンプレッサーの両方で次のロジックを使用する必要があります。
Context(CFP)
コンテキスト（CFP）
During context initialization, the value of context(CFP) MUST be set to a nonzero value if the Checksum Coverage field differs from the length of the UDP-Lite packet, for any one IR or IR-DYN packet sent (compressor) or received (decompressor); otherwise, the value MUST be set to zero.
コンテキストの初期化中に、送信（圧縮）または受信（IR）または受信（IR） 減圧装置）; それ以外の場合は、値をゼロに設定する必要があります。
Context(CFI)
コンテキスト（CFI）
During context initialization, the value of context(CFI) MUST be set to a nonzero value if the Checksum Coverage field is equal to the length of the UDP-Lite packet within an IR or an IR-DYN packet sent (compressor) or received (decompressor); otherwise, the value MUST be set to zero.
コンテキストの初期化中に、Checksum CoverageフィールドがIR内のUDP-Liteパケットまたは送信（コンプレッサー）または受信（IR-DYN）パケットの長さに等しい場合、context（CFI）の値はゼロ以外の値に設定する必要があります 減圧装置）; それ以外の場合は、値をゼロに設定する必要があります。
The general packet format, as defined in RFC 3095 [2], is modified to include an additional field for the UDP-Lite checksum coverage. A packet type is also defined to handle the specific semantics and characteristics of this field.
RFC 3095 [2]で定義されている一般的なパケット形式は、UDP-Liteチェックサムカバレッジ用の追加フィールドを含むように変更されています。 このフィールドの特定のセマンティクスと特性を処理するために、パケットタイプも定義されます。
The general packet format of a compressed ROHC UDP-Lite header is similar to the compressed ROHC RTP header ([2], section 5.7), with modifications to the Checksum field, as well as additional fields for handling multiple IP headers and for the UDP-Lite checksum coverage:
圧縮ROHC UDP-Liteヘッダーの一般的なパケット形式は、圧縮ROHC RTPヘッダー（[2]、セクション5.7）に似ていますが、チェックサムフィールドに加えて、複数のIPヘッダーを処理するための追加フィールドおよびUDP -ライトチェックサムカバレッジ：
--- --- --- --- --- --- --- ---
: List of : variable, given by static chain
/ dynamic chains / (does not include SN)
: for additional IP headers : see also [3], section 3.2.
--- --- --- --- --- --- --- ---
: : 2 octets,
+ UDP-Lite Checksum Coverage + if context(CFP) = 1 or
: : if packet type = CCE (see 5.3.2)
--- --- --- --- --- --- --- ---
: :
+ UDP-Lite Checksum + 2 octets
: :
--- --- --- --- --- --- --- ---
The list of dynamic header chains carries the dynamic header part for each IP header in excess of the initial two, if there is any (as indicated by the presence of corresponding header parts in the static chain). Note that there is no sequence number at the end of the chain, as SN is present within compressed base headers.
ダイナミックヘッダーチェーンのリストには、最初の2つを超える場合、各IPヘッダーのダイナミックヘッダーパーツがあります（スタティックチェーンに対応するヘッダーパーツが存在することで示されます）。 SNは圧縮ベースヘッダー内に存在するため、チェーンの最後にシーケンス番号がないことに注意してください。
The order of the fields following the optional extension of the general ROHC packet format is the same as the order between the fields in the uncompressed header.
一般的なROHCパケット形式のオプションの拡張子に続くフィールドの順序は、非圧縮ヘッダーのフィールド間の順序と同じです。
When the CRC is calculated, the Checksum Coverage field is CRC-DYNAMIC.
CRCが計算されるとき、チェックサムカバレッジフィールドはCRC-DYNAMICです。
The ROHC profiles for UDP-Lite define a packet type to handle the various possible change patterns of the checksum coverage. This packet type may be used to manipulate the context values that control the presence of the Checksum Coverage field within the general packet format (i.e., context(CFP)) and how the field is decompressed (i.e., context(CFI)). The 2-octet Checksum Coverage field is always present within the format of this packet (see section 5.3.1).
UDP-LiteのROHCプロファイルは、パケットタイプを定義して、チェックサムカバレッジのさまざまな変化パターンを処理します。 このパケットタイプは、一般的なパケット形式（つまり、context（CFP））内のチェックサムカバレッジフィールドの存在を制御するコンテキスト値と、フィールドの圧縮解除方法（つまり、context（CFI））を操作するために使用できます。 2オクテットチェックサムカバレッジフィールドは、このパケットの形式内に常に存在します（セクション5.3.1を参照）。
This type of packet is named Checksum Coverage Extension, or CCE, and its updating properties depend on the final two bits of the packet type octet (see format below). A naming scheme of the form CCE(<some_property>) is used to uniquely identify the properties of a particular CCE packet.
このタイプのパケットは、チェックサムカバレッジエクステンション（CCE）と呼ばれ、その更新プロパティは、パケットタイプオクテットの最後の2ビットに依存します（以下の形式を参照）。 CCE（<some_property>）という形式の命名スキームを使用して、特定のCCEパケットのプロパティを一意に識別します。
Although this packet type defines its own format, it may be considered as an extension mechanism for packets of type 2, 1, or 0 [2]. This is achieved by substitution of the packet type identifier of the first octet of the base header (the "outer" identifier) with one of the unused packet types from RFC 3095 [2]. The substituted identifier is then moved to the first octet of the remainder of the base header (the "inner" identifier).
このパケットタイプは独自の形式を定義しますが、タイプ2、1、または0のパケットの拡張メカニズムと見なされる場合があります[2]。 これは、ベースヘッダーの最初のオクテットのパケットタイプ識別子（「外部」識別子）をRFC 3095 [2]の未使用パケットタイプの1つに置き換えることで実現されます。 置換された識別子は、ベースヘッダーの残りの最初のオクテット（「内部」識別子）に移動されます。
The format of the ROHC UDP-Lite CCE packet type is as follows:
ROHC UDP-Lite CCEパケットタイプの形式は次のとおりです。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 F | K | Outer packet type identifier
+===+===+===+===+===+===+===+===+
: : (with inner type identifier)
/ Inner Base header / variable number of bits, given by
: : the inner packet type identifier
+---+---+---+---+---+---+---+---+
F,K: F,K = 00 is reserved at framework level (IR-DYN);
F,K = 01 indicates CCE();
F,K = 10 indicates CCE(ON);
F,K = 11 indicates CCE(OFF).
Updating properties: The updating properties of the inner packet type carried within any of the CCE packets are always maintained. CCE(ON) and CCE(OFF) MUST NOT be used to extend R-0 and R-1* headers. In addition, CCE(ON) always updates context(CFP); CCE(OFF) always updates context(CFP), context(CFI), and context(UDP-Lite Checksum Coverage).
プロパティの更新：いずれかのCCEパケット内で伝達される内部パケットタイプの更新プロパティは常に維持されます。 R-0およびR-1 *ヘッダーを拡張するためにCCE（ON）およびCCE（OFF）を使用してはなりません。 さらに、CCE（ON）は常にcontext（CFP）を更新します。 CCE（OFF）は、常にcontext（CFP）、context（CFI）、およびcontext（UDP-Lite Checksum Coverage）を更新します。
Appendix B provides an expanded view of the resulting format of the CCE packet type.
付録Bでは、CCEパケットタイプの結果形式の拡張ビューを提供します。
Aside from the updating properties of the inner packet type carried within CCE(), this packet does not update any other context values. CCE() thus is mode-agnostic; e.g., it can extend any of packet types 2, 1, and 0, regardless of the current mode of operation [2].
CCE（）内で伝送される内部パケットタイプのプロパティの更新は別として、このパケットは他のコンテキスト値を更新しません。 したがって、CCE（）はモードに依存しません。 たとえば、現在の動作モードに関係なく、パケットタイプ2、1、および0のいずれかを拡張できます[2]。
CCE() may be used when the checksum coverage deviates from the change pattern assumed by the compressor, where the field could previously be compressed. This packet is useful if the occurrence of such deviations is rare.
CCE（）は、チェックサムカバレッジが、フィールドが以前に圧縮されていたコンプレッサーが想定する変更パターンから逸脱する場合に使用できます。 このパケットは、このような逸脱の発生がまれな場合に役立ちます。
In addition to the updating properties of the inner packet type, CCE(ON) updates context(CFP) to a nonzero value; i.e., it effectively turns on the presence of the Checksum Coverage field within the general packet format. This is useful when the predominant change pattern of the checksum coverage precludes its compression.
内部パケットタイプのプロパティの更新に加えて、CCE（ON）はcontext（CFP）をゼロ以外の値に更新します。 つまり、一般的なパケット形式内のチェックサムカバレッジフィールドの存在を効果的にオンにします。 これは、チェックサムカバレッジの主な変更パターンがその圧縮を排除する場合に役立ちます。
CCE(ON) can extend any of the context-updating packets of type 2, 1, and 0; that is, packets with a compressed header containing a CRC [2]. Specifically, R-0 and R-1* headers MUST NOT be extended by using CCE(ON).
CCE（ON）は、タイプ2、1、および0のコンテキスト更新パケットを拡張できます。 つまり、CRCを含む圧縮ヘッダーを持つパケット[2]。 特に、CCE（ON）を使用してR-0およびR-1 *ヘッダーを拡張してはなりません。
In addition to the updating properties of the inner packet type, CCE(OFF) updates context(CFP) to a value of zero; i.e., it effectively turns off the presence of the Checksum Coverage field within the general packet format. This is useful when the change pattern of the checksum coverage seldom deviates from the pattern assumed by the compressor.
内部パケットタイプのプロパティの更新に加えて、CCE（OFF）はcontext（CFP）をゼロの値に更新します。 つまり、一般的なパケット形式内のチェックサムカバレッジフィールドの存在を効果的にオフにします。 これは、チェックサムカバレッジの変更パターンがコンプレッサーが想定するパターンからほとんど逸脱しない場合に役立ちます。
CCE(OFF) also updates context(CFI) to a nonzero value, if field(UDP-Lite Checksum Coverage) is equal to the packet length; otherwise, it must be set to zero. Note that when context(CFI) is updated by using packet type CCE(OFF), a match of field(Checksum Coverage) with the packet length always has precedence over a match with context(Checksum Coverage). Finally, context(UDP-Lite Checksum Coverage) is also updated by CCE(OFF).
CCE（OFF）は、field（UDP-Lite Checksum Coverage）がパケット長に等しい場合、context（CFI）もゼロ以外の値に更新します。 それ以外の場合は、ゼロに設定する必要があります。 パケットタイプCCE（OFF）を使用してコンテキスト（CFI）を更新すると、フィールド（チェックサムカバレッジ）とパケット長の一致が常にコンテキスト（チェックサムカバレッジ）との一致より優先されることに注意してください。 最後に、コンテキスト（UDP-Liteチェックサムカバレッジ）もCCE（OFF）によって更新されます。
Similarly to CCE(ON), CCE(OFF) can extend any of the context updating packets of type 2, 1, and 0 [2].
CCE（ON）と同様に、CCE（OFF）は、タイプ2、1、および0のパケットを更新するコンテキストを拡張できます[2]。
If hdr(UDP-Lite Checksum Coverage) is different from context(UDP-Lite Checksum Coverage) and different from the packet length when context(CFP) is zero, the Checksum Coverage field cannot be compressed. In addition, if hdr(UDP-Lite Checksum Coverage) is different from the packet length when context(CFP) is zero and context(CFI) is nonzero, the Checksum Coverage field cannot be compressed by either. For both cases, the field must be sent uncompressed using a CCE packet, or the context must be reinitialized by using an IR packet.
hdr（UDP-Lite Checksum Coverage）がcontext（UDP-Lite Checksum Coverage）と異なり、context（CFP）がゼロの場合のパケット長と異なる場合、Checksum Coverageフィールドは圧縮できません。 さらに、context（CFP）がゼロでcontext（CFI）がゼロ以外の場合、hdr（UDP-Lite Checksum Coverage）がパケット長と異なる場合、Checksum Coverageフィールドはどちらによっても圧縮できません。 どちらの場合も、CCEパケットを使用して非圧縮でフィールドを送信するか、IRパケットを使用してコンテキストを再初期化する必要があります。
For packet types other than IR, IR-DYN, and CCE that are received when the value of context(CFP) is zero, the Checksum Coverage field must be decompressed by using the value stored in the context if the value of context(CFI) is zero; otherwise, the field is inferred from the length of the UDP-Lite packet derived from the IP module.
context（CFP）の値がゼロのときに受信されるIR、IR-DYN、およびCCE以外のパケットタイプの場合、context（CFI）の値がコンテキストに格納されている場合、 ゼロです; それ以外の場合、フィールドは、IPモジュールから派生したUDP-Liteパケットの長さから推測されます。
The profiles defined in this document allow the compressor to decline a mode transition requested by the decompressor. This is achieved by redefining the Mode parameter for the value mode = 0 (in packet types UOR-2, IR, and IR-DYN) as follows (see also [3], section 3.4):
このドキュメントで定義されたプロファイルは、コンプレッサーが減圧装置によって要求されたモード移行を断ることを可能にします。 これは、値mode = 0（パケットタイプUOR-2、IR、およびIR-DYN）のModeパラメーターを次のように再定義することによって実現されます（[3]、セクション3.4も参照）。
Mode: Compression mode. 0 = (C)ancel Mode Transition
モード：圧縮モード。 0 =（C）ancelモード遷移
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.
0に設定されたModeパラメーターを受信すると、圧縮解除プログラムは現在の動作モードにとどまる必要があり、拒否されたモードのモード移行要求をそれ以上送信しないようにする必要があります。
This feedback option informs the compressor that the decompressor does not have sufficient memory resources to handle the context of the packet stream required by the current compressed structure.
このフィードバックオプションは、現在の圧縮構造に必要なパケットストリームのコンテキストを処理するための十分なメモリリソースがデコンプレッサにないことをコンプレッサに通知します。
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 requiring less decompressor memory resources or stop compressing the packet stream.
CONTEXT_MEMORYオプションを受信すると、コンプレッサーは、より少ない解凍メモリーリソースを必要とする方法でパケットストリームを圧縮するアクションを実行するか、パケットストリームの圧縮を停止する必要があります。
The profiles for UDP-Lite support compression of the IP-ID field with constant behavior, with the addition of the Static IP Identifier (SID) flag within the dynamic part of the chain used to initialize the IPv4 header, as follows (see also [3], section 3.3):
UDP-Liteのプロファイルは、次のように、IPv4ヘッダーの初期化に使用されるチェーンの動的部分内の静的IP識別子（SID）フラグの追加により、一定の動作でIP-IDフィールドの圧縮をサポートします（[ 3]、セクション3.3）：
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:
IRおよびIR-DYNパケットの場合：
The logic is the same as that for the respective ROHC profiles for UDP, with the addition that field (SID) must be kept in the context.
ロジックは、UDPのそれぞれのROHCプロファイルのロジックと同じですが、追加でフィールド（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 by using Offset IP-ID encoding (see [2], section 4.5.5) using p = 0 and default-slope(IP-ID offset) = 0.
value（RND）= 0およびcontext（SID）= 0の場合、hdr（IP-ID）はOffset IP-IDエンコーディング（[2]、セクション4.5.5を参照）を使用して圧縮され、p = 0およびdefault-slope（ 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).
value（RND）= 0およびcontext（SID）= 1の場合、hdr（IP-ID）は一定で圧縮されます。 hdr（IP-ID）は、context（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.
value（RND）= 1の場合、IP-IDは非圧縮hdr（IP-ID）です。 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 the respective ROHC profiles for UDP [2].
注：他のすべてのフィールドは、UDPのそれぞれのROHCプロファイルと同じです[2]。
The security considerations of RFC 3095 [2] apply integrally to this document, without modification.
RFC 3095 [2]のセキュリティに関する考慮事項は、変更せずにこのドキュメントに統合的に適用されます。
ROHC profile identifiers 0x0007 (ROHC RTP/UDP-Lite) and 0x0008 (ROHC UDP-Lite) have been reserved by the IANA for the profiles defined in this document (RFC 4019).
ROHCプロファイル識別子0x0007（ROHC RTP / UDP-Lite）および0x0008（ROHC UDP-Lite）は、このドキュメント（RFC 4019）で定義されたプロファイル用にIANAによって予約されています。
Two ROHC profile identifiers must be reserved by the IANA for the profiles defined in this document. Since profile number 0x0006 is being saved for the TCP/IP (ROHC-TCP) profile, profile numbers 0x0007 and 0x0008 are the most suitable unused identifiers available, and should thus be used. As for previous ROHC profiles, profile numbers 0xnn07 and 0xnn08 must also be reserved for future variants of these profiles. The registration suggested for the "RObust Header Compression (ROHC) Profile Identifiers" name space:
2つのROHCプロファイル識別子は、このドキュメントで定義されたプロファイルのためにIANAによって予約されなければなりません。 プロファイル番号0x0006はTCP / IP（ROHC-TCP）プロファイル用に保存されているため、プロファイル番号0x0007と0x0008は使用可能な最も適切な未使用の識別子であるため、使用する必要があります。 以前のROHCプロファイルに関しては、プロファイル番号0xnn07および0xnn08もこれらのプロファイルの将来のバリアント用に予約する必要があります。 「RObust Header Compression（ROHC）Profile Identifiers」名前空間の登録が提案されました：
OLD: 0x0006-0xnn7F To be Assigned by IANA
OLD：0x0006-0xnn7F IANAによって割り当てられる
NEW: 0xnn06 To be Assigned by IANA 0x0007 ROHC RTP/UDP-Lite [RFC4019] 0xnn07 Reserved 0x0008 ROHC UDP-Lite [RFC4019] 0xnn08 Reserved 0x0009-0xnn7F To be Assigned by IANA
新規：0xnn06 IANAにより割り当てられる0x0007 ROHC RTP / UDP-Lite [RFC4019] 0xnn07予約済み0x0008 ROHC UDP-Lite [RFC4019] 0xnn08予約済み0x0009-0xnn7F IANAにより割り当てられる
The author would like to thank Lars-Erik Jonsson, Kristofer Sandlund, Mark West, Richard Price, Gorry Fairhurst, Fredrik Linstroem and Mats Nordberg for useful reviews and discussions around this document.
著者は、この文書に関する有用なレビューと議論について、Lars-Erik Jonsson、Kristofer Sandlund、Mark West、Richard Price、Gorry Fairhurst、Fredrik Linstroem、およびMats Nordbergに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[2] 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): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[2] Bormann、C.、Burmeister、C.、Degermark、M.、Fukushima、H.、Hannu、H.、Jonsson、LE。、Hakenberg、R.、Koren、T.、Le、K.、Liu、 Z.、Martensson、A。、宮崎、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T。、およびH. Zheng、「堅牢なヘッダー圧縮（ROHC）：フレームワークと4つのプロファイル：RTP、UDP、 ESP、および非圧縮」、RFC 3095、2001年7月。
[3] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A Compression Profile for IP", RFC 3843, June 2004.
[3]ジョンソン、L-E。 およびG. Pelletier、「堅牢なヘッダー圧縮（ROHC）：IPの圧縮プロファイル」、RFC 3843、2004年6月。
[4] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[4] Larzon、LA、Degermark、M.、Pink、S.、Jonsson、LE、およびG. Fairhurst、「ライトウェイトユーザーデータグラムプロトコル（UDP-Lite）」、RFC 3828、2004年7月。
[5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[5]ポステル、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[6] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[7] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[7]ポステル、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[8] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーションのトランスポートプロトコル」、STD 64、RFC 3550、2003年7月。
Appendix A. Detailed Classification of Header Fields
付録A.ヘッダーフィールドの詳細な分類
This section summarizes the difference from the classification found in the corresponding appendix in RFC 3095 [2] and similarly provides conclusions about how the various header fields should be handled by the header compression scheme to optimize compression and functionality. These conclusions are separated based on the behavior of the UDP-Lite Checksum Coverage field and use the expected change patterns described in section 3.2 of this document.
このセクションでは、RFC 3095 [2]の対応する付録にある分類との違いを要約し、同様に、圧縮と機能を最適化するためにヘッダー圧縮スキームでさまざまなヘッダーフィールドを処理する方法について結論を示します。 これらの結論は、UDP-Liteチェックサムカバレッジフィールドの動作に基づいて分離され、このドキュメントのセクション3.2で説明されている予想される変更パターンを使用します。
A.1. UDP-Lite Header Fields
A.1。 UDP-Liteヘッダーフィールド
The following table summarizes a possible classification for the UDP-Lite header fields in comparison with the classification for UDP, using the same classes as in RFC 3095 [2].
次の表は、RFC 3095 [2]と同じクラスを使用して、UDPの分類と比較したUDP-Liteヘッダーフィールドの可能な分類をまとめたものです。
Header fields of UDP-Lite and UDP:
UDP-LiteおよびUDPのヘッダーフィールド：
+-------------------+-------------+
| UDP-Lite | UDP |
+-------------------+--------+-------------------+-------------+
| Header | Size | Class | Class |
| Field | (bits) | | |
+-------------------+--------+-------------------+-------------+
| Source Port | 16 | STATIC-DEF | STATIC-DEF |
| Destination Port | 16 | STATIC-DEF | STATIC-DEF |
| Checksum Coverage | 16 | INFERRED | |
| | | STATIC | |
| | | CHANGING | |
| Length | 16 | | INFERRED |
| Checksum | 16 | CHANGING | CHANGING |
+-------------------+--------+-------------------+-------------+
Source and Destination Port
送信元ポートと宛先ポート
Same as for UDP. Specifically, these fields are part of the definition of a stream and must thus be constant for all packets in the stream. The fields are therefore classified as STATIC-DEF.
UDPと同じです。 特に、これらのフィールドはストリームの定義の一部であるため、ストリーム内のすべてのパケットで一定でなければなりません。 したがって、フィールドはSTATIC-DEFとして分類されます。
Checksum Coverage
チェックサムの適用範囲
This field specifies which part of the UDP-Lite datagram is covered by the checksum. It may have a value of zero or be equal to the datagram length if the checksum covers the entire datagram, or it may have any value between eight octets and the length of the datagram to specify the number of octets protected by the checksum, calculated from the first octet of the UDP-Lite header. The value of this field may vary for each packet, and this makes the value unpredictable from a header-compression perspective.
このフィールドは、UDP-Liteデータグラムのどの部分がチェックサムでカバーされるかを指定します。 チェックサムがデータグラム全体をカバーする場合、値はゼロまたはデータグラムの長さと等しい場合があります。または、8オクテットとデータグラムの長さの間の任意の値で、チェックサムによって保護されるオクテットの数を指定します。 UDP-Liteヘッダーの最初のオクテット。 このフィールドの値はパケットごとに異なる場合があり、これによりヘッダー圧縮の観点から値が予測不能になります。
Checksum
チェックサム
The information used for the calculation of the UDP-Lite checksum is governed by the value of the checksum coverage and minimally includes the UDP-Lite header. The checksum is a changing field that must always be sent as-is.
UDP-Liteチェックサムの計算に使用される情報は、チェックサムカバレッジの値によって管理され、UDP-Liteヘッダーが最小限含まれます。 チェックサムは変化するフィールドであり、常にそのまま送信する必要があります。
The total size of the fields in each class, for each expected change pattern (see section 3.2), is summarized in the tables below:
各クラスのフィールドの合計サイズは、予想される各変更パターン（セクション3.2を参照）について、以下の表にまとめられています。
Pattern 1:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| INFERRED | 2 | Checksum Coverage
| STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 2 | Checksum
+------------+---------------+
Pattern 2:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| STATIC-DEF | 4 | Source Port / Destination Port
| STATIC | 2 | Checksum Coverage
| CHANGING | 2 | Checksum
+------------+---------------+
Pattern 3:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 4 | Checksum Coverage / Checksum
+------------+---------------+
A.2. Header Compression Strategies for UDP-Lite
A.2。 UDP-Liteのヘッダー圧縮戦略
The following table revisits the corresponding table (table A.1) for UDP from [2] (section A.2) and classifies the changing fields based on the change patterns previously identified in section 3.2.
次の表は、[2]（セクションA.2）からのUDPの対応するテーブル（テーブルA.1）を再検討し、セクション3.2で以前に特定された変更パターンに基づいて変更フィールドを分類します。
Header compression strategies for UDP-Lite:
+----------+---------+-------------+-----------+-----------+
| Field | Pattern | Value/Delta | Class | Knowledge |
+==========+=========+=============+===========+===========+
| | #1 | Value | CHANGING | INFERRED |
| Checksum |---------+-------------+-----------+-----------+
| Coverage | #2 | Value | RC | UNKNOWN |
| |---------+-------------+-----------+-----------+
| | #3 | Value | IRREGULAR | UNKNOWN |
+----------+---------+-------------+-----------+-----------+
| Checksum | All | Value | IRREGULAR | UNKNOWN |
+----------+---------+-------------+-----------+-----------+
A.2.1. Transmit initially but be prepared to update
A.2.1。 最初に送信するが、更新の準備をする
UDP-Lite Checksum Coverage (Patterns #1 and #2)
UDP-Liteチェックサムカバレッジ（パターン＃1および＃2）
A.2.2. Transmit as-is in all packets
A.2.2。 すべてのパケットでそのまま送信
UDP-Lite Checksum UDP-Lite Checksum Coverage (Pattern #3)
UDP-LiteチェックサムUDP-Liteチェックサムのカバレッジ（パターン＃3）
Appendix B. Detailed Format of the CCE Packet Type
付録B. CCEパケットタイプの詳細な形式
This section provides an expanded view of the format of the CCE packet, based on the general ROHC RTP compressed header [2] and the general format of a compressed header of the ROHC IP-Only profile [3]. The modifications necessary to carry the base header of a packet of type 2, 1 or 0 [2] within the CCE packet format, along with the additional fields to properly handle compression of multiple IP headers, result in the following structure for the CCE packet type:
このセクションは、一般的なROHC RTP圧縮ヘッダー[2]およびROHC IP-Onlyプロファイル[3]の圧縮ヘッダーの一般的なフォーマットに基づいて、CCEパケットのフォーマットの拡大図を提供します。 複数のIPヘッダーの圧縮を適切に処理するための追加フィールドとともに、CCEパケット形式内でタイプ2、1または0 [2]のパケットのベースヘッダーを運ぶために必要な変更は、CCEパケットの次の構造をもたらします。 タイプ：
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : If for small CIDs and CID 1 - 15
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 F | K | Outer packet type identifier
+---+---+---+---+---+---+---+---+
: :
/ 0, 1, or 2 octets of CID / 1 - 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
| First octet of base header | (with "inner" type indication)
+---+---+---+---+---+---+---+---+
/ Remainder of base header / Variable number of bits
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: :
/ Extension / See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
: :
+ IP-ID of outer IPv4 header + See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
/ AH data for outer list / See RFC 3095 [2], section 5.7.
--- --- --- --- --- --- --- ---
: :
+ GRE checksum + See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
: :
+ IP-ID of inner IPv4 header + See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
/ AH data for inner list / See RFC 3095 [2], section 5.7.
--- --- --- --- --- --- --- ---
: :
+ GRE checksum + See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
: List of : Variable, given by static chain
/ dynamic chains / (includes no SN).
: for additional IP headers : See [3], section 3.2.
--- --- --- --- --- --- --- ---
: :
+ UDP-Lite Checksum Coverage + 2 octets
: :
+---+---+---+---+---+---+---+---+
: :
+ UDP-Lite Checksum + 2 octets
: :
+---+---+---+---+---+---+---+---+
F,K: F,K = 00 is reserved at framework level (IR-DYN);
F,K = 01 indicates CCE();
F,K = 10 indicates CCE(ON);
F,K = 11 indicates CCE(OFF).
Note that this document does not define (F,K) = 00, as this would collide with the IR-DYN packet type already reserved at the ROHC framework level.
このドキュメントは（F、K）= 00を定義していないことに注意してください。これは、ROHCフレームワークレベルで既に予約されているIR-DYNパケットタイプと衝突するためです。
Author's Address
著者の住所
Ghyslain Pelletier Ericsson AB Box 920 SE-971 28 Lulea, Sweden
Ghyslain Pelletier Ericsson AB Box 920 SE-971 28 Lulea、Sweden
Phone: +46 840 429 43 Fax : +46 920 996 21 EMail: ghyslain.pelletier@ericsson.com
電話：+46840429 43ファックス：+46920 996 21電子メール：ghyslain.pelletier@ericsson.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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.
この文書は、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開示のコピーおよび利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用許可の取得を試みた結果を取得できます。 IETFオンラインIPRリポジトリ（http://www.ietf.org/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のietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在インターネット協会によって提供されています。