[要約] RFC 4815は、RFC 3095の修正と明確化を行ったものであり、RObust Header Compression（ROHC）に関するものです。このRFCの目的は、ROHCプロトコルの誤りや不明瞭な点を修正し、より効果的なヘッダ圧縮を実現することです。
Network Working Group L-E. Jonsson
Request for Comments: 4815 K. Sandlund
Updates: 3095, 3241, 3843, 4019, 4362 G. Pelletier
Category: Standards Track P. Kremer
February 2007
RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095
堅牢なヘッダー圧縮（ROHC）：RFC 3095への修正と説明
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 IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles for IP (Internet Protocol), UDP (User Datagram Protocol), RTP (Real-Time Transport Protocol), and ESP (Encapsulating Security Payload). Some parts of the specification are unclear or contain errors that may lead to misinterpretations that may impair interoperability between different implementations. This document provides corrections, additions, and clarifications to RFC 3095; this document thus updates RFC 3095. In addition, other clarifications related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) and RFC 4109 (ROHC UDP-Lite profiles) are also provided.
RFC 3095は、IP（インターネットプロトコル）、UDP（ユーザーデータグラムプロトコル）、RTP（リアルタイムトランスポートプロトコル）、およびESP（セキュリティペイロードのカプセル）の堅牢なヘッダー圧縮（ROHC）フレームワークとプロファイルを定義します。仕様の一部は不明確であるか、異なる実装間の相互運用性を損なう可能性のある誤解につながる可能性のあるエラーを含んでいます。このドキュメントは、RFC 3095の修正、追加、および説明を提供します。したがって、このドキュメントはRFC 3095を更新します。さらに、RFC 3241（PPPを超えるROHC）、RFC 3843（ROHC IPプロファイル）、RFC 4109（ROHC UDP-Liteプロファイル）に関連する他の明確化も提供されます。
Table of Contents
目次
1. Introduction and Terminology ....................................3
2. CRC Calculation and Coverage ....................................4
2.1. CRC Calculation ............................................4
2.2. Padding Octet and CRC Calculations .........................4
2.3. CRC Coverage in CRC Feedback Options .......................5
2.4. CRC Coverage of the ESP NULL Header ........................5
3. Mode Transition .................................................5
3.1. Feedback During Mode Transition to U- and O-Mode ...........5
3.1.1. Mode Transition Procedures Allowing Sparse Feedback .6
3.1.2. Transition from Reliable to Optimistic Mode .........7
3.1.3. Transition to Unidirectional Mode ...................8
3.2. Feedback During Mode Transition ............................8
3.3. Packet Decoding During Mode Transition .....................9
4. Timestamp Encoding ..............................................9
4.1. Encoding Used for Compressed TS Bits .......................9
4.2. (De)compression of TS without Transmitted TS Bits .........10
4.3. Interpretation Intervals for TS Encoding ..................11
4.4. Scaled RTP Timestamp Encoding .............................11
4.4.1. TS_STRIDE for Scaled Timestamp Encoding ............11
4.4.2. TS Wraparound with Scaled Timestamp Encoding .......12
4.4.3. Algorithm for Scaled Timestamp Encoding ............12
4.5. Recalculating TS_OFFSET ...................................14
4.6. TS_STRIDE and the Tsc Flag in Extension 3 .................14
4.7. Using Timer-Based Compression .............................15
5. List Compression ...............................................15
5.1. CSRC List Items in RTP Dynamic Chain ......................15
5.2. Multiple Occurrences of the CC Field ......................15
5.3. Bit Masks in List Compression .............................16
5.4. Headers Compressed with List Compression ..................16
5.5. ESP NULL Header List Compression ..........................17
5.6. Translation Tables and Indexes for IP Extension Headers ...17
5.7. Reference List ............................................17
5.8. Compression of AH and GRE Sequence Numbers ................18
6. Updating Properties ............................................19
6.1. Implicit Updates ..........................................19
6.2. Updating Properties of UO-1* ..............................20
6.3. Context Updating Properties for IR Packets ................20
6.4. RTP Padding Field (R-P) in Extension 3 ....................20
6.5. RTP eXtension bit (X) in dynamic part .....................21
7. Context management and CID/context Reuse .......................21
7.1. Persistence of Decompressor Contexts ......................21
7.2. CID/Context Reuse .........................................21
7.2.1. Reusing a CID/Context with the Same Profile ........22
7.2.2. Reusing a CID/Context with a Different Profile .....23
8. Other Protocol Clarifications ..................................23
8.1. Meaning of NBO ............................................23
8.2. IP-ID .....................................................23
8.3. Extension-3 in UOR-2* Packets .............................24
8.4. Multiple Occurrences of the M Bit .........................24
8.5. Multiple SN options in one feedback packet ................24
8.6. Multiple CRC Options in One Feedback Packet ...............25
8.7. Responding to Lost Feedback Links .........................25
8.8. UOR-2 in Profile 0x0002 (UDP) and Profile 0x0003 (ESP) ....25
8.9. Sequence Number LSB's in IP Extension Headers .............25
8.10. Expecting UOR-2 ACKs in O-Mode ...........................26
8.11. Context Repairs, TS_STRIDE and TIME_STRIDE ...............26
9. ROHC Negotiation ...............................................27
10. PROFILES Sub-option in ROHC-over-PPP ..........................27
11. Constant IP-ID Encoding in IP-only and UPD-Lite Profiles ......27
12. Security Considerations .......................................28
13. Acknowledgments ...............................................28
14. References ....................................................28
14.1. Normative References .....................................28
14.2. Informative References ...................................29
Appendix A. Sample CRC Algorithm ..................................30
RFC 3095 [1] defines the RObust Header Compression (ROHC) framework and profiles for IP (Internet Protocol) [8][9], UDP (User Datagram Protocol) [10], RTP (Real-Time Transport Protocol) [11], and ESP (Encapsulating Security Payload) [12]. During implementation and interoperability testing of RFC 3095, some ambiguities and common misinterpretations have been identified, as well as a few errors.
RFC 3095 [1]は、IP（インターネットプロトコル）[8] [9]、UDP（ユーザーデータグラムプロトコル）[10]、RTP（リアルタイムトランスポートプロトコル）[8] [9]の堅牢なヘッダー圧縮（ROHC）フレームワークとプロファイルを定義します。、およびESP（セキュリティペイロードをカプセル化する）[12]。RFC 3095の実装および相互運用性テスト中、いくつかの曖昧さと一般的な誤解が特定されており、いくつかのエラーが特定されています。
This document summarizes identified issues and provides corrections needed for implementations of RFC 3095 to interoperate, i.e., it constitutes an update to RFC 3095. This document also provides other clarifications related to common misinterpretations of the specification. References to RFC 3095 should, therefore, also include this document.
このドキュメントは、特定された問題を要約し、RFC 3095の実装に相互運用するために必要な修正を提供します。つまり、RFC 3095の更新を構成します。このドキュメントは、仕様の一般的な誤解に関連する他の明確化も提供します。したがって、RFC 3095への参照には、このドキュメントも含める必要があります。
In addition, some clarifications and corrections are also provided for RFC 3241 (ROHC over PPP) [2], RFC 3843 (ROHC IP-only profile) [4], and RFC 4019 (ROHC UDP-Lite profiles) [5], which are thus also updated by this document. Furthermore, RFC 4362 (ROHC Link-Layer Assisted Profile) [7] is implicitly updated by this document, since RFC 4362 is also based on RFC 3095.
さらに、RFC 3241（PPP上のROHC）[2]、RFC 3843（ROHC IPのみのプロファイル）[4]、およびRFC 4019（ROHC UDP-Liteプロファイル）[5]には、いくつかの説明と修正も提供されています。したがって、このドキュメントによっても更新されます。さらに、RFC 4362はRFC 3095にも基づいているため、RFC 4362（ROHCリンクレイヤーアシストプロファイル）[7]はこのドキュメントで暗黙的に更新されます。
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 [6].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [6]に記載されているように解釈される。
When a section of this document makes formal corrections, additions or invalidations to text in RFC 3095, this is clearly summarized. The text from RFC 3095 that is being addressed is given and labeled "INCOMPLETE", "INCORRECT", or "INCORRECT AND INVALIDATED", followed by the correct text labeled "CORRECTED", where applicable. When text is added that does not simply correct text in previous specifications, it is given with the label "FORMAL ADDITION".
このドキュメントのセクションが、RFC 3095のテキストの正式な修正、追加、または無効化を行う場合、これは明確に要約されています。対処されているRFC 3095のテキストは、「不完全」、「正しくない」、または「間違っていて無効」とラベル付けされ、該当する場合は「修正」というラベルの付いたテキストが付属しています。以前の仕様で単にテキストを修正しないテキストが追加された場合、ラベル「正式な追加」で与えられます。
In this document, a reference to a section in RFC 3095 [1] is written as RFC 3095-Section <number>.
このドキュメントでは、RFC 3095 [1]のセクションへの参照は、RFC 3095-Section <number>として記述されています。
RFC 3095-Section 5.9 defines polynomials for 3-, 7-, and 8-bit Cyclic Redundancy Checks (CRCs), but it does not specify what algorithm is used. The 3-, 7- and 8-bit CRCs are calculated using the CRC algorithm defined in [3].
RFC 3095セクション5.9は、3、7、および8ビットの環状冗長チェック（CRC）の多項式を定義しますが、使用されるアルゴリズムを指定しません。3、7ビット、および8ビットのCRCは、[3]で定義されたCRCアルゴリズムを使用して計算されます。
A Perl implementation of the algorithm can be found in Appendix A of this document.
アルゴリズムのPERL実装は、このドキュメントの付録Aにあります。
RFC 3095-Section 5.9.1 is incomplete, as it does not mention how to handle the padding octet in CRC calculations for IR and IR-DYN packets. Padding isn't meant to be a meaningful part of a packet and is not included in the CRC calculation. As a result, the CRC does not cover the Add-CID octet for CID 0, either.
RFC 3095-Section 5.9.1は不完全です。IRおよびIR-DynパケットのCRC計算でパディングオクテットを処理する方法については言及していないためです。パディングは、パケットの意味のある部分であることを意図したものではなく、CRC計算には含まれていません。その結果、CRCはCID 0のADD-CIDオクテットもカバーしません。
INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.9.1):
不完全なRFC 3095テキスト（RFC 3095-Section 5.9.1）：
"The CRC in the IR and IR-DYN packet is calculated over the entire IR or IR-DYN packet, excluding Payload and including CID or any Add-CID octet."
「IRおよびIR-DynパケットのCRCは、ペイロードを除外し、CIDまたはADD-CIDオクテットを含むIRまたはIR-Dynパケット全体で計算されます。」
CORRECTED TEXT:
修正されたテキスト：
"The CRC in the IR and IR-DYN packet is calculated over the entire IR or IR-DYN packet, excluding Payload, Padding and including CID or any Add-CID octet, except for the add-CID octet for CID 0."
「IRおよびIR-DynパケットのCRCは、CID 0のADD-CIDオクテットを除き、ペイロード、パディング、CIDまたはADD-CIDオクテットを除き、IRまたはIR-Dynパケット全体で計算されます。」
RFC 3095-Section 5.7.6.3 is incomplete, as it does not mention how the "size" field is handled when calculating the 8-bit CRC used in the CRC feedback option. Since the "size" field is an extension of the "code" field, it must be treated in the same way.
RFC 3095-Section 5.7.6.3は、CRCフィードバックオプションで使用されている8ビットCRCを計算するときに「サイズ」フィールドがどのように処理されるかについて言及していないため、不完全です。「サイズ」フィールドは「コード」フィールドの拡張であるため、同じ方法で扱う必要があります。
INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7.6.3):
不完全なRFC 3095テキスト（RFC 3095-Section 5.7.6.3）：
"The CRC option contains an 8-bit CRC computed over the entire feedback payload, without the packet type and code octet, but including any CID fields, using the polynomial of section 5.9.1."
「CRCオプションには、パケットタイプとコードオクテットを使用せずに、フィードバックペイロード全体にわたって計算された8ビットCRCが含まれていますが、セクション5.9.1の多項式を使用してCIDフィールドを含みます。」
CORRECTED TEXT:
修正されたテキスト：
"The CRC option contains an 8-bit CRC computed over the entire feedback payload including any CID fields but excluding the packet type, the 'Size' field and the 'Code' octet, using the polynomial of Section 5.9.1."
「CRCオプションには、CIDフィールドを含むフィードバックペイロード全体にわたって計算された8ビットCRCが含まれていますが、セクション5.9.1の多項式を使用して、パケットタイプ、「サイズ」フィールド、「コード」オクテットを除外します。」
RFC 3095-Section 5.8.7 gives the CRC coverage of the ESP NULL [13] header as "Entire ESP header". This must be interpreted as including only the initial part of the header (i.e., Security Parameter Index (SPI) and sequence number), and not the trailer part at the end of the payload. Therefore, the ESP NULL header has the same CRC coverage as the ESP header used in the ESP profile (RFC 3095-Section 5.7.7.7).
RFC 3095-Section 5.8.7は、ESP Null [13]ヘッダーのCRCカバレッジを「ESPヘッダー全体」として提供します。これは、ペイロードの最後にあるトレーラー部分ではなく、ヘッダーの最初の部分（つまり、セキュリティパラメーターインデックス（SPI）とシーケンス番号）のみを含めると解釈する必要があります。したがって、ESP Nullヘッダーは、ESPプロファイル（RFC 3095-Section 5.7.7.7）で使用されているESPヘッダーと同じCRCカバレッジを持っています。
RFC 3095-Section 5.6.1 states that during mode transitions, while the D_TRANS parameter is I, the decompressor sends feedback for each received packet. This restrictive behavior prevents the decompressor from using a sparse feedback algorithm during mode transitions.
RFC 3095-Section 5.6.1は、モード遷移中に、D_TRANSパラメーターはIであるが、減圧器は受信した各パケットのフィードバックを送信すると述べています。この制限的な動作により、減圧装置はモード遷移中にスパースフィードバックアルゴリズムを使用することを防ぎます。
To reduce transmission overhead and computational complexity (including CRC calculation) associated with feedback packets sent for each decompressed packet during mode transition, a decompressor MAY be implemented with slightly modified mode transition procedures compared to those defined in [1], as described in this section.
このセクションで説明したように、[1]で定義されたものと比較して、モードトランジション中に減圧された各パケットに送信されたフィードバックパケットに関連付けられた送信オーバーヘッドと計算の複雑さ（CRC計算を含む）を削減するフィードバックパケットに関連付けられています。。
These enhanced procedures should be considered only as a possible improvement to a decompressor implementation, since interoperability is not affected in any way. A decompressor implemented according to the optimized procedures will interoperate with an RFC 3095 compressor, as well as a decompressor implemented according to the procedures described in RFC 3095.
これらの強化された手順は、相互運用性が何らかの影響を受けないため、減圧装置の実装の可能性のある改善とのみ考慮される必要があります。最適化された手順に従って実装された減圧器は、RFC 3095コンプレッサーと、RFC 3095で説明されている手順に従って実装された減圧器と相互運用します。
The purpose of these enhanced transition procedures is to allow the decompressor to sparsely send feedback for packets decompressed during the second half of the transition procedure, i.e., after an appropriate IR/IR-DYN/UOR-2 packet has been received from the compressor. This is achieved by allowing the decompressor transition parameter (D_TRANS) to be set to P (Pending) at that stage, as shown in the transition diagrams of Sections 3.1.2 and 3.1.3 below.
これらの拡張された遷移手順の目的は、遷移手順の後半に減圧されたパケットのフィードバックを減圧装置に送信できるようにすることです。これは、下のセクション3.1.2および3.1.3の遷移図に示されているように、その段階で減圧遷移パラメーター（D_TRANS）をその段階でP（保留中）に設定できるようにすることによって達成されます。
This enhanced transition, where feedback need not be sent for every decompressed packet, does however introduce some considerations in case feedback messages would be lost. Specifically, there is a risk for a deadlock situation when a transition from R-mode is performed; if no feedback message successfully reaches the compressor, the transition is never completed. For transition between U-mode and O-mode, there is also a small risk for reduced compression efficiency.
ただし、フィードバックが減圧されたパケットごとにフィードバックを送信する必要がないこの拡張された遷移は、フィードバックメッセージが失われた場合にいくつかの考慮事項を導入します。具体的には、Rモードからの移行が実行されると、デッドロックの状況のリスクがあります。フィードバックメッセージがコンプレッサーに正常に届かない場合、遷移は完了しません。UモードとOモード間の遷移については、圧縮効率の低下のリスクもわずかです。
To avoid this, the decompressor MUST continue to send feedback at least periodically, as well as when in a Pending transition state. This is equivalent to enhancing the definition of the D_TRANS parameter in RFC 3095-Section 5.6.1, to include the definition of a Pending state:
これを回避するために、減圧装置は、少なくとも定期的にフィードバックを送信し続ける必要があります。これは、保留中の状態の定義を含めるために、RFC 3095-Section 5.6.1のD_TRANSパラメーターの定義を強化することと同等です。
- D_TRANS: Possible values for the D_TRANS parameter are (I)NITIATED, (P)ENDING, and (D)ONE. D_TRANS MUST be initialized to D, and a mode transition can be initiated only when D_TRANS is D. While D_TRANS is I, the decompressor sends a NACK or ACK carrying a CRC option for each packet received. When D_TRANS is set to P, the decompressor does not have to send a NACK or ACK for each packet received, but it MUST continue to send feedback with some periodicity, and all feedback packets sent MUST include the CRC option. This ensures that all mode transitions will be completed also in case of feedback losses.
- D_TRANS：D_TRANSパラメーターの可能な値は、（i）ニチエート、（p）終了、および（d）1つです。D_TransはDに初期化する必要があり、D_TRANSがDの場合にのみモード遷移を開始できます。D_TRANSがIである間、Decompressorは受信した各パケットのCRCオプションを運ぶNACKまたはACKを送信します。D_TRANSがPに設定されている場合、減圧器は受信した各パケットにNACKまたはACKを送信する必要はありませんが、期間性でフィードバックを送信し続ける必要があり、送信されたすべてのフィードバックパケットにはCRCオプションが含まれている必要があります。これにより、フィードバックの損失の場合にもすべてのモード遷移が完了することが保証されます。
The modifications affect transitions to Optimistic and Unidirectional modes of operation (i.e., the transitions described in RFC 3095- Section 5.6.5 and RFC 3095-Section 5.6.6) and make those transition diagrams more consistent with the diagram describing the transition to R-mode.
変更は、楽観的および単方方向の動作モードへの遷移に影響を与えます（つまり、RFC 3095-セクション5.6.5およびRFC 3095セクション5.6.6で説明されている遷移）。モード。
The enhanced procedure for transition from Reliable to Optimistic mode is shown below:
信頼性から楽観的モードへの移行のための拡張手順を以下に示します。
Compressor Decompressor
----------------------------------------------
| |
| ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = O | |
|->->->-+ IR/IR-DYN/UOR-2(SN,O) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_TRANS = P
|->-.. | D_MODE = O
| ACK(SN,O) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
| |
The enhanced procedure for transition to Unidirectional mode is shown on the following figure:
単方向モードへの移行の拡張手順は、次の図に示されています。
Compressor Decompressor
----------------------------------------------
| |
| ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = U | |
|->->->-+ IR/IR-DYN/UOR-2(SN,U) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_TRANS = P
|->-.. |
| ACK(SN,U) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
| | D_MODE= U
RFC 3095-Section 5.6.1 states that feedback is always used during mode transitions. However, the text then continues by making concrete applications of the rule in an inconsistent way, making it unclear when CRCs are used. Further, the text does not define how the compressor should act during mode transitions based on feedback not protected by CRCs, i.e., whether or not to carry out mode transition actions. The proper behavior from the compressor is to perform any action related to mode transitions only when the feedback is protected by the CRC option.
RFC 3095-Section 5.6.1は、モード遷移中は常にフィードバックが使用されると述べています。ただし、テキストは、ルールの具体的なアプリケーションを一貫性のない方法で作成することで継続され、CRCがいつ使用されるかが不明確になります。さらに、テキストは、CRCによって保護されていないフィードバックに基づいて、モード遷移中にコンプレッサーがどのように動作するか、つまりモード移行アクションを実行するかどうかを定義するものではありません。コンプレッサーからの適切な動作は、フィードバックがCRCオプションによって保護されている場合にのみ、モード遷移に関連するアクションを実行することです。
INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.6.1):
不完全なRFC 3095テキスト（RFC 3095-Section 5.6.1）：
"As a safeguard against residual errors, all feedback sent during a mode transition MUST be protected by a CRC, i.e., the CRC option MUST be used."
「残留エラーに対するセーフガードとして、モード遷移中に送信されるすべてのフィードバックは、CRCによって保護されなければなりません。つまり、CRCオプションを使用する必要があります。」
CORRECTED TEXT:
修正されたテキスト：
"As a safeguard against residual errors, all feedback sent by the decompressor during a mode transition MUST be protected by a CRC, i.e., the CRC option MUST be used. The compressor MUST ignore feedback information related to mode transition if the feedback is not protected by the CRC option."
「残留エラーに対するセーフガードとして、モード遷移中に減圧器が送信するすべてのフィードバックはCRCによって保護する必要があります。つまり、CRCオプションを使用する必要があります。コンプレッサーは、フィードバックが保護されていない場合、モード遷移に関連するフィードバック情報を無視する必要があります。CRCオプションによって。」
One more related issue that requires clarifications comes from the following text at the end of RFC 3095-Section 5.6.1:
明確化を必要とするもう1つの関連する問題は、RFC 3095-Section 5.6.1の終わりに次のテキストから発生します。
"While D_TRANS is I, the decompressor sends a NACK or ACK carrying a CRC option for each received packet."
「D_TransはIですが、Decompressorは、受信したパケットごとにCRCオプションを運ぶNACKまたはACKを送信します。」
However, RFC 3095-Section 5.5.2.2 already stated that for R-mode, feedback is never sent for packets that do not update the context, i.e., for packets that do not carry a CRC, such as R-0 and R-1*.
ただし、RFC 3095-Section 5.5.2.2は、Rモードでは、コンテキストを更新しないパケット、つまりR-0やR-1などのCRCを運ばないパケットに対してフィードバックが送信されないことをすでに述べています。*。
This means that when D_TRANS=I during mode transition, a decompressor operating in R-mode sends an acknowledgement for each packet it receives and MUST use the sequence number that corresponds to the packet that last updated the context, i.e., the decompressor MUST NOT use the sequence number of the R-0 or the R-1* packet.
これは、モード遷移中にD_TRANS = Iの場合、Rモードで動作する減圧器が受信する各パケットの確認を送信し、コンテキストを最後に更新したパケットに対応するシーケンス番号、つまり減圧器は使用してはならないことを意味します。R-0またはR-1*パケットのシーケンス番号。
The purpose of a mode transition is to ensure that the compressor and the decompressor coherently move from one mode of operation to another using a three-way handshake. At one point during the mode transition, the decompressor acknowledges the reception of one (or more) IR, IR-DYN or UOR-2 packet(s) that have mode bits set to the new mode. Packets of type 0 or type 1 that are received up to this point are decompressed using the old mode, while afterwards they are decompressed using the new mode. If the enhanced transition procedures described in Section 3.1 are used, the setting of the D_TRANS parameter to P represents this breakpoint. The successful decompression of a packet of type 0 or type 1 completes the mode transition.
モード遷移の目的は、コンプレッサーと減圧器が、3方向の握手を使用して、ある動作モードから別のモードに首尾一貫して移動することを保証することです。モード遷移中のある時点で、減圧器は、モードビットが新しいモードに設定された1つ（またはそれ以上）、IR-Dyn、またはUOR-2パケットの受信を認めます。この時点までに受信されるタイプ0またはタイプ1のパケットは、古いモードを使用して減圧されますが、その後、新しいモードを使用して減圧されます。セクション3.1で説明されている拡張された遷移手順が使用される場合、PへのD_TRANSパラメーターの設定はこのブレークポイントを表します。タイプ0またはタイプ1のパケットの減圧が成功すると、モード遷移が完了します。
RTP Timestamp (TS) values are always encoded using W-LSB encoding, both when sent scaled and unscaled. When no TS bits are transmitted in a compressed packet, TS is always scaled. If a compressed packet carries an Extension 3 and field(Tsc)=0, the compressed packet must thus always carry unscaled TS bits. For TS values sent in Extension 3, W-LSB encoded values are sent using the self-describing variable-length format (RFC 3095-Section 4.5.6), and this applies to both scaled and unscaled values.
RTPタイムスタンプ（TS）の値は、スケーリングと非スケーリングの両方で、W-LSBエンコードを使用して常にエンコードされます。圧縮パケットにTSビットが送信されない場合、TSは常にスケーリングされます。圧縮されたパケットに拡張機能3とフィールド（TSC）= 0がある場合、圧縮パケットは常に非衝撃的なTSビットを運ぶ必要があります。拡張3で送信されたTS値の場合、W-LSBエンコード値は、自己記述変数変数形式（RFC 3095-Section 4.5.6）を使用して送信され、これはスケーリングされた値と非スケール値の両方に適用されます。
When ROHC RTP operates using its most efficient packet types, apart from packet type identification and the error detection CRC, only RTP sequence number (SN) bits are transmitted in RTP compressed headers. All other fields are then omitted either because they are unchanged or because they can be reconstructed through a function from the SN (i.e., by combining the transmitted SN bits with state information from the context). Fields that can be inferred from the SN are the IP Identification (IP-ID) and the RTP Timestamp (TS).
ROHC RTPが、パケットタイプの識別とエラー検出CRCとは別に、最も効率的なパケットタイプを使用して動作する場合、RTP圧縮ヘッダーでRTPシーケンス数（SN）ビットのみが送信されます。その後、他のすべてのフィールドは、変更されていないか、SNから関数を介して再構築できるため（つまり、コンテキストからの状態情報と状態情報を組み合わせることにより）省略されます。SNから推測できるフィールドは、IP識別（IP-ID）とRTPタイムスタンプ（TS）です。
IP-ID compression and decompression, both with and without transmitted IP-ID bits in the compressed header, are well defined in RFC 3095-Section 4.5.5 (see Section 8.2). For the TS field, however, RFC 3095 only defines how to decompress based on actual TS bits in the compressed header, either scaled or unscaled, but not how to infer the TS from the SN when there are no TS bits present in the compressed header.
圧縮ヘッダーに送信されたIP-IDビットの有無にかかわらず、IP-IDの圧縮と減圧は、RFC 3095セクション4.5.5で明確に定義されています（セクション8.2を参照）。ただし、TSフィールドの場合、RFC 3095は、圧縮ヘッダーの実際のTSビットに基づいて減圧する方法のみを定義します。。
When no TS bits are received in the compressed header, the scaled TS value is reconstructed assuming a linear extrapolation from the SN, i.e., delta_TS = delta_SN * default-slope, where delta_SN and delta_TS are both signed integers. RFC 3095-Section 5.7 defines the potential values for default-slope.
圧縮ヘッダーでTSビットが受信されない場合、SNからの線形外挿、つまりDelta_Ts = delta_sn * default-slopeを想定して、スケーリングされたTS値が再構築されます。RFC 3095-Section 5.7は、デフォルトスロープの潜在的な値を定義します。
INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7):
不完全なRFC 3095テキスト（RFC 3095-Section 5.7）：
"If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before compression (see section 4.5.3), and default-slope(TS) = 1.
「値（TSC）= 1の場合、圧縮前にスケーリングされたRTPタイムスタンプエンコードが使用されます（セクション4.5.3を参照）、デフォルトスロープ（TS）= 1。
If value(Tsc) = 0, the Timestamp value is compressed as-is, and
default-slope(TS) = value(TS_STRIDE)."
CORRECTED TEXT:
修正されたテキスト：
"When a compressed header with no TS bits is received, the scaled TS value is reconstructed assuming a linear extrapolation from the SN, i.e., delta_TS = delta_SN * default-slope(TS).
「TSビットのない圧縮ヘッダーが受信されると、SNからの線形外挿、つまりdelta_ts = delta_sn * default-slope（TS）を想定して、スケーリングされたTS値が再構築されます。
If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before compression (see Section 4.5.3), and default-slope(TS) = 1.
値（TSC）= 1の場合、圧縮前にスケーリングされたRTPタイムスタンプエンコードが使用されます（セクション4.5.3を参照）、デフォルトスロープ（TS）= 1。
If value(Tsc) = 0, the Timestamp value is compressed as-is, and
default-slope(TS) = value(TS_STRIDE). If a packet with no TS
bits is received with Tsc = 0, the decompressor MUST discard the
packet."
INCORRECT AND INVALIDATED RFC 3095 TEXT (Section RFC 3095-5.5.1.2):
RFC 3095テキストが不正確で無効なテキスト（セクションRFC 3095-5.5.1.2）：
"For example, in a typical case where the string pattern has the form of non-SN-field = SN * slope + offset, one ACK is enough if the slope has been previously established by the decompressor (i.e., only the new offset needs to be synchronized). Otherwise, two ACKs are required since the decompressor needs two headers to learn both the new slope and the new offset."
「たとえば、文字列パターンに非SN-field = sn *勾配オフセットの形式がある典型的なケースでは、勾配が減圧器によって以前に確立された場合に1つのACKで十分です（つまり、新しいオフセットのみが必要です。それ以外の場合、減圧器には新しい勾配と新しいオフセットの両方を学習するために2つのヘッダーが必要なため、2つのアクセントが必要です。」
Consequently, there is no other slope value than the default-slope, as defined in RFC 3095-Section 5.7.
その結果、RFC 3095-Section 5.7で定義されているように、デフォルトスロープ以外の勾配値はありません。
RFC 3095-Section 4.5.4 defines the interpretation interval, p, for timer-based compression of the RTP timestamp. However, RFC 3095- Section 5.7 defines a different interpretation interval, which is defined as the interpretation interval to use for all TS values. It is thus unclear which p-value to use, at least for timer-based compression.
RFC 3095セクション4.5.4は、RTPタイムスタンプのタイマーベースの圧縮の解釈間隔Pを定義します。ただし、RFC 3095-セクション5.7では、すべてのTS値に使用する解釈間隔として定義される別の解釈間隔を定義します。したがって、少なくともタイマーベースの圧縮については、使用するp値は不明です。
The way this should be interpreted is that the p-value differs depending on whether or not timer-based compression is enabled.
これを解釈する方法は、タイマーベースの圧縮が有効になっているかどうかによってp値が異なることです。
For timer-based compression (TIME_STRIDE set to a non-zero value), the interpretation interval is:
タイマーベースの圧縮（ゼロ以外の値に設定されているTime_Stride）の場合、解釈間隔は次のとおりです。
p = 2^(k-1) - 1 (as per RFC 3095-Section 4.5.4)
Otherwise, the interpretation interval is:
それ以外の場合、解釈間隔は次のとおりです。
p = 2^(k-2) - 1 (as per RFC 3095-Section 5.7)
This section redefines the algorithm for scaled RTP timestamp encoding, defined as a 5-step procedure in RFC 3095-Section 4.5.3. Two formal errors have been corrected, as described in sub-sections 4.4.1 and 4.4.2 below, and the whole algorithm has been reworked to be more concise and to use well-defined terminology. The resulting text can be found in 4.4.3 below.
このセクションでは、RFC 3095セクション4.5.3の5段階の手順として定義されたスケーリングされたRTPタイムスタンプエンコードのアルゴリズムを再定義します。下のサブセクション4.4.1および4.4.2で説明されているように、2つの正式なエラーが修正されており、アルゴリズム全体がより簡潔になり、明確に定義された用語を使用するように再加工されています。結果のテキストは、以下の4.4.3にあります。
RFC 3095 defines the timestamp stride (TS_STRIDE) as the expected increase in the timestamp value between two RTP packets with consecutive sequence numbers. TS_STRIDE is set by the compressor and explicitly communicated to the decompressor, and it is used as the scaling factor for scaled TS encoding.
RFC 3095は、連続したシーケンス番号を持つ2つのRTPパケット間のタイムスタンプ値の予想される増加として、タイムスタンプストライド（TS_STRIDE）を定義します。TS_STRIDEはコンプレッサーによって設定され、減圧器に明示的に通信され、スケーリングされたTSエンコードのスケーリング係数として使用されます。
The relation between TS and TS_SCALED, given by the following equality in RFC 3095-Section 4.5.3, defines the mathematical meaning of TS_STRIDE:
TSとTS_Scaledの関係は、RFC 3095-Section 4.5.3の次の平等によって与えられ、TS_STRIDEの数学的意味を定義します。
TS = TS_SCALED * TS_STRIDE + TS_OFFSET
TS_SCALED is incompletely written as TS / TS_STRIDE in the compression step following the above core equality. This formula is incorrect both because it excludes TS_OFFSET and because it would prevent a TS_STRIDE value of 0, which is an alternative not excluded by the definition or by the core equality above. If "/" were a generally unambiguously defined operation meaning "the integral part of the result from dividing X by Y", the absence of TS_OFFSET could be explained, but the formula would still lack a proper output for TS_STRIDE equal to 0. The formula of "2. Compression" is thus valid only with the following requirements:
TS_Scaledは、上記のコア平等に続いて圧縮ステップでTS / TS_STRIDEとして不完全に記述されています。この式は、TS_OFFSETを除外し、TS_STRIDE値が0のTS_STRIDE値を妨げるため、上記のコア等価によって除外されない代替手段であるため、間違っています。"/"が一般に明確に定義されていない操作を意味した場合、「xをyで除算した結果の積分部分」を意味する場合、ts_offsetの存在が説明できますが、式には0に等しいts_strideの適切な出力がありません。したがって、「2.圧縮」は、次の要件でのみ有効です。
a) "/" means "the integral part of the result from dividing X by Y"
a) "/"は「xをyで割ることからの結果の積分部分を意味します」
b) TS_STRIDE>0 (TS is never sent scaled when TS_STRIDE=0)
b) TS_STRIDE> 0（TSはTS_STRIDE = 0のときにスケーリングされることはありません）
RFC 3095-Section 4.5.3 states in points 4 and 5 that the compressor is not required to initialize TS_OFFSET at wraparound, but that it is required to increase the number of bits sent for the scaled TS value when there is a TS wraparound. The decompressor is also required to detect and cope with TS wraparound, including updating TS_OFFSET.
RFC 3095-section 4.5.3ポイント4および5の状態は、コンプレッサーがラップアラウンドでTS_OFFSEを初期化する必要はないが、TSラップアラウンドがあるときにスケーリングされたTS値に送信されるビット数を増やす必要があると述べています。TS_offsetの更新を含むTSラップアラウンドを検出して対処するためには、減圧器も必要です。
This method is not interoperable and not robust. The gain is also insignificant, as TS wraparound happens very seldomly. Therefore, the compressor should reinitialize TS_OFFSET upon TS wraparound, by sending an unscaled TS.
この方法は相互運用可能ではなく、堅牢ではありません。TSラップアラウンドは非常にめったに起こらないため、利益も取るに足らないものです。したがって、コンプレッサーは、スケールのTSを送信することにより、TSラップアラウンドにTS_OFFSETを再現する必要があります。
INCORRECT RFC 3095 TEXT (RFC 3095-Section 4.5.3):
誤ったRFC 3095テキスト（RFC 3095-Section 4.5.3）：
"1. Initialization: The compressor sends to the decompressor the value of TS_STRIDE and the absolute value of one or several TS fields. The latter are used by the decompressor to initialize TS_OFFSET to (absolute value) modulo TS_STRIDE. Note that TS_OFFSET is the same regardless of which absolute value is used, as long as the unscaled TS value does not wrap around; see 4) below.
"1.初期化：コンプレッサーは減圧器にTS_STRIDEの値と1つまたは複数のTSフィールドの絶対値を送信します。後者は、ts_offsetを（絶対値）modulo ts_strideに初期化するために使用されます。以下の未スケーリングのTS値が包まれない限り、どの絶対値が使用されているかに関係なく、以下を参照してください。
2. Compression: After initialization, the compressor no longer compresses the original TS values. Instead, it compresses the downscaled values: TS_SCALED = TS / TS_STRIDE. The compression method could be either W-LSB encoding or the timer-based encoding described in the next section.
2. 圧縮：初期化後、コンプレッサーは元のTS値を圧縮しなくなりました。代わりに、ダウンスケールの値を圧縮します：ts_scaled = ts / ts_stride。圧縮方法は、W-LSBエンコーディングまたは次のセクションで説明するタイマーベースのエンコードのいずれかです。
3. Decompression: When receiving the compressed value of TS_SCALED, the decompressor first derives the value of the original TS_SCALED. The original RTP TS is then calculated as TS = TS_SCALED * TS_STRIDE + TS_OFFSET.
3. 減圧：TS_Scaledの圧縮値を受信する場合、減圧器は最初に元のTS_Scaledの値を導き出します。次に、元のRTP TSは、TS = TS_SCALED * TS_STRIDE TS_OFFSETとして計算されます。
4. Offset at wraparound: Wraparound of the unscaled 32-bit TS will invalidate the current value of TS_OFFSET used in the equation above. For example, let us assume TS_STRIDE = 160 = 0xA0 and the current TS = 0xFFFFFFF0. TS_OFFSET is then 0x50 = 80. Then if the next RTP TS = 0x00000130 (i.e., the increment is 160 * 2 = 320), the new TS_OFFSET should be 0x00000130 modulo 0xA0 = 0x90 = 144. The compressor is not required to re-initialize TS_OFFSET at wraparound. Instead, the decompressor MUST detect wraparound of the unscaled TS (which is trivial) and update TS_OFFSET to TS_OFFSET = (Wrapped around unscaled TS) modulo TS_STRIDE"
4. ラップアラウンドでのオフセット：スケーリングされていない32ビットTSのラップアラウンドは、上記の方程式で使用されているTS_OFFSETの現在の値を無効にします。たとえば、ts_stride = 160 = 0xa0と現在のts = 0xfffffff0と仮定します。Ts_offsetは0x50 = 80です。次に、次のRTP TS = 0x00000130（つまり、増分が160 * 2 = 320）の場合、新しいTS_OFFSESTは0x00000130 modulo 0xa0 = 0x90 = 144である必要があります。ラップアラウンドのTS_OFFSET。代わりに、減圧装置は、非スケーリングTS（些細な）のラップアラウンドを検出し、ts_offsetをts_offset =（rapped rapped rapped）modulo ts_strideに更新する必要があります。
CORRECTED TEXT:
修正されたテキスト：
"1. Initialization and updating of RTP TS scaling function: The compressor sends to the decompressor the value of TS_STRIDE along with an unscaled TS. These are both needed by the decompressor to initialize TS_OFFSET as hdr(TS) modulo field(TS_STRIDE). Note that TS_OFFSET is the same for any TS as long as TS_STRIDE does not change and as long as the unscaled TS value does not wrap around; see 4) below.
「1. RTP TSスケーリング関数の初期化と更新：コンプレッサーは、非衝撃的なTSとともにTS_STRIDEの値を減圧器に送信します。これらは両方とも、TS_OFFSESEをHDR（TS）モジュロフィールドとして初期化するために必要です（TS_STRIDE）。TS_OFFSETは、TS_STRIDEが変更されない限り、任意のTSに対して同じであり、非スケールのTS値が包まれない限り、以下を参照してください。
2. Compression: After initialization, the compressor no longer compresses the unscaled TS values. Instead, it compresses the scaled values. The compression method can be either W-LSB encoding or timer-based encoding.
2. 圧縮：初期化後、コンプレッサーは非衝突されたTS値を圧縮しなくなりました。代わりに、スケーリングされた値を圧縮します。圧縮方法は、W-LSBエンコードまたはタイマーベースのエンコードのいずれかです。
3. Decompression: When receiving a (compressed) TS_SCALED, the field is first decompressed, and the unscaled RTP TS is then calculated as TS = TS_SCALED * TS_STRIDE + TS_OFFSET.
3. 減圧：（圧縮）TS_Scaledを受信すると、フィールドが最初に減圧され、非スケールのRTP TSがTS = TS_SCALED * TS_STRIDE TS_OFFSESEとして計算されます。
4. Offset at wraparound: If the value of TS_STRIDE is not equal to a power of two, wraparound of the unscaled 32-bit TS will change the value of TS_OFFSET. When this happens, the compressor SHOULD reinitialize TS_OFFSET by sending unscaled TS, as in 1 above."
4. ラップアラウンドでのオフセット：TS_STRIDEの値が2つのパワーに等しくない場合、無防備な32ビットTSのラップアラウンドはTS_OFFSESTの値を変更します。これが発生した場合、コンプレッサーは、上記の1のように、非スケーリングTSを送信することによりTS_OFFSETを再現する必要があります。」
INCORRECT AND INVALIDATED RFC 3095 TEXT (RFC 3095-Section 4.5.3):
RFC 3095テキストが不正確で無効なテキスト（RFC 3095-Section 4.5.3）：
The entire point 5, i.e. the entire text starting from "5. Interpretation interval at wraparound ...", down to and including the block of text that starts with "Let a be the number of LSBs" and that ends with "...interpretation interval is b." is incorrect and is thus invalid.
ポイント5、つまり、「5。ラップアラウンドの解釈間隔...」から始まるテキスト全体が、「aをLSBの数とする」で始まり、「。。解釈間隔はbです。」正しくないため、無効です。
TS can be sent unscaled if the TS value change does not match the established TS_STRIDE, but the TS_STRIDE might still stay unchanged. To ensure correct decompression of subsequent packets, the decompressor MUST therefore always recalculate TS_OFFSET (RTP TS modulo TS_STRIDE) when a packet with an unscaled TS value is received.
TS値の変化が確立されたTS_STRIDEと一致しない場合、TSは無視できますが、TS_STRIDEはまだ変更されていない場合があります。したがって、後続のパケットの正しい減圧を確保するには、非控えめなTS値を持つパケットが受信された場合、減圧器は常にTS_OFFSET（RTP TS Modulo TS_STRIDE）を再計算する必要があります。
The Tsc flag in Extension 3 indicates whether or not TS is scaled. The value of the Tsc flag thus applies to all TS bits, as well as if there are no TS bits in the extension itself. When TS is scaled, it is always scaled using context(TS_STRIDE). The legend for Extension 3 in RFC 3095-Section 5.7.5 incorrectly states that value(TS_STRIDE) is used for scaled TS.
拡張3のTSCフラグは、TSがスケーリングされているかどうかを示します。したがって、TSCフラグの値は、すべてのTSビットに適用され、拡張機能自体にTSビットがない場合に適用されます。TSがスケーリングされると、コンテキスト（TS_STRIDE）を使用して常にスケーリングされます。RFC 3095-Section 5.7.5の拡張3の凡例は、値（TS_STRIDE）がスケーリングされたTSに使用されることを誤って述べています。
If TS_STRIDE is present in Extension 3, as indicated by the Tss flag being set, the compressed header SHOULD carry unscaled TS bits; i.e., the Tsc flag SHOULD NOT be set when Tss is set since an unscaled TS is needed together with TS_STRIDE to recalculate the TS_OFFSET. If TS_STRIDE is included in a compressed header with scaled TS, the decompressor must ignore and discard field(TS_STRIDE).
TS_STRIDEが拡張3に存在する場合、TSSフラグが設定されていることで示されているように、圧縮ヘッダーには無防備なTSビットが搭載されている必要があります。つまり、TS_STRIDEと一緒にTS_OFFSETを再計算するためにTS_STRIDEと一緒に必要なため、TSSが設定されている場合はTSCフラグを設定しないでください。TS_STRIDEがスケーリングされたTSを備えた圧縮ヘッダーに含まれている場合、減圧器はフィールド（TS_STRIDE）を無視して破棄する必要があります。
INCORRECT RFC 3095 TEXT (RFC 3095-Section 5.7.5):
誤ったRFC 3095テキスト（RFC 3095-Section 5.7.5）：
"Tsc: Tsc = 0 indicates that TS is not scaled;
Tsc = 1 indicates that TS is scaled according to section
4.5.3, using value(TS_STRIDE).
Context(Tsc) is always 1. If scaling is not desired, the
compressor will establish TS_STRIDE = 1."
CORRECTED TEXT:
修正されたテキスト：
"Tsc: Tsc = 0 indicates that TS is not scaled; Tsc = 1 indicates that TS is scaled according to Section 4.5.3, using context(TS_STRIDE).
「TSC：TSC = 0は、TSがスケーリングされていないことを示します。TSC= 1は、TSがセクション4.5.3に従ってコンテキスト（TS_STRIDE）を使用してスケーリングされていることを示します。
Context(Tsc) is always 1. If scaling is not desired, the compressor will establish TS_STRIDE = 1.
コンテキスト（TSC）は常に1です。スケーリングが望ましくない場合、コンプレッサーはTS_STRIDE = 1を確立します。
If field(Tsc) = 1, and if TSS = 1 (meaning that TS_STRIDE is present in the extension), field(TS_STRIDE) MUST be ignored and discarded."
フィールド（TSC）= 1、およびTSS = 1（TS_STRIDEが拡張機能に存在することを意味する場合）の場合、フィールド（TS_STRIDE）を無視して破棄する必要があります。」
When the compressor re-establishes a new value for TS_STRIDE using Extension 3, it should send unscaled TS bits together with TS_STRIDE.
コンプレッサーが拡張機能3を使用してTS_STRIDEの新しい値を再確立すると、TS_STRIDEとともに非控えめなTSビットを送信する必要があります。
Timer-based compression of the RTP timestamp, as described in RFC 3095-Section 4.5.4, may be used to reduce the number of transmitted timestamp bits (bytes) needed when the timestamp cannot be inferred from the SN. Timer-based compression is only used for decompression of compressed headers that contains a TS field; otherwise, when no timestamp bits are present, the timestamp is linearly inferred from the SN (see Section 4.2 of this document).
RFC 3095セクション4.5.4で説明されているように、RTPタイムスタンプのタイマーベースの圧縮は、SNからタイムスタンプを推測できない場合に必要な送信されたタイムスタンプビット（バイト）の数を減らすために使用できます。タイマーベースの圧縮は、TSフィールドを含む圧縮ヘッダーの減圧にのみ使用されます。それ以外の場合、タイムスタンプビットが存在しない場合、タイムスタンプはSNから直線的に推測されます（このドキュメントのセクション4.2を参照）。
Whether or not to use timer-based compression is controlled by the TIME_STRIDE control field, which can be set by either an IR, an IR-DYN, or a compressed packet with Extension 3. Before timer-based compression can be used, the decompressor has to inform the compressor (on a per-channel basis) about its clock resolution by sending a CLOCK feedback option for any CID on the channel. The compressor can then initiate timer-based compression by sending (on a per-context basis) a non-zero TIME_STRIDE to the decompressor. When the compressor is confident that the decompressor has received the TIME_STRIDE value, it can switch to timer-based compression.
タイマーベースの圧縮を使用するかどうかは、IR、IR-DYN、または拡張機能3を備えた圧縮パケットのいずれかによって設定できるTime_Strideコントロールフィールドによって制御されるかどうか。チャネル上のCIDに対してクロックフィードバックオプションを送信することにより、クロック解像度についてコンプレッサーに（チャネルごとに）通知する必要があります。コンプレッサーは、ゼロ以外のtime_strideを非偏光子に送信することにより、タイマーベースの圧縮を開始できます。コンプレッサーが減圧器がtime_stride値を受信していると確信している場合、タイマーベースの圧縮に切り替えることができます。
RFC 3095-Section 5.7.7.6 defines the static and dynamic parts of the RTP header. This section indicates a 'Generic CSRC list' field in the dynamic chain, which has a variable length (see RFC 3095-Section 5.8.6). This field is always at least one octet in size, even if the list is empty (as opposed to the CSRC list in the uncompressed RTP header, which is not present when the RTP CC field is set to 0).
RFC 3095-Section 5.7.7.6 RTPヘッダーの静的部分と動的部分を定義します。このセクションでは、変動長の動的チェーンの「ジェネリックCSRCリスト」フィールドを示します（RFC 3095-Section 5.8.6を参照）。このフィールドは、リストが空になっていても、常に少なくとも1つのオクテットです（圧縮されていないRTPヘッダーのCSRCリストとは対照的に、RTP CCフィールドが0に設定されている場合は存在しません）。
The static and the dynamic parts of the RTP header are defined in RFC 3095-Section 5.7.7.6. In the dynamic part, a CC field indicates the number of CSRC items present in the 'Generic CSRC list'. Another CC field also appears within the 'Generic CSRC list' (RFC 3095-Section 5.8.6.1), because Encoding Type 0 is always used in the dynamic chain. Both CC fields have the same meaning: the value of the CC field determines the number of XI items in the CSRC list for Encoding Type 0, and it is not used otherwise. Therefore, the following applies:
RTPヘッダーの静的部分と動的部分は、RFC 3095-Section 5.7.7.6で定義されています。動的部分では、CCフィールドは「ジェネリックCSRCリスト」に存在するCSRCアイテムの数を示します。エンコードタイプ0は常に動的チェーンで使用されるため、別のCCフィールドは「汎用CSRCリスト」（RFC 3095-Section 5.8.6.1）にも表示されます。両方のCCフィールドには同じ意味があります。CCフィールドの値は、タイプ0のエンコードのCSRCリスト内のXIアイテムの数を決定し、それ以外の場合は使用されません。したがって、以下が適用されます。
FORMAL ADDITION TO RFC 3095:
RFC 3095への正式な追加：
"The first octet in the dynamic part of the RTP header contains a CC field, as defined in Section 5.7.7.6. A second occurrence appears in the 'Generic CSRC list', which is also in the dynamic part of the RTP header, where Encoding Type 0 is used according to the format defined in RFC 3095-5.8.6.1.
「RTPヘッダーの動的部分の最初のオクテットには、セクション5.7.7.6で定義されているように、CCフィールドが含まれています。2回目の発生は「ジェネリックCSRCリスト」に表示されます。これは、RTPヘッダーの動的部分にもあります。エンコードタイプ0は、RFC 3095-5.8.6.1で定義されている形式に従って使用されます。
The compressor MUST set both occurrences of the CC field to the same value.
コンプレッサーは、CCフィールドの両方の発生を同じ値に設定する必要があります。
The decompressor MUST use the value of the CC field from the Encoding Type 0 within the Generic CRSC list, and it MUST thus ignore the first occurrence of the CC field."
減圧器は、汎用CRSCリスト内のエンコードタイプ0からCCフィールドの値を使用する必要があるため、CCフィールドの最初の発生を無視する必要があります。」
The insertion and/or removal schemes, described in RFC 3095-Sections 5.8.6.2 - 5.8.6.4, use bit masks to indicates insertion or removal positions within the reference list. The size of the bit mask can be 7 bits or 15 bits.
RFC 3095 -Sections 5.8.6.2-5.8.6.4で説明されている挿入および/または除去スキームは、ビットマスクを使用して、参照リスト内の挿入または除去位置を示します。ビットマスクのサイズは、7ビットまたは15ビットです。
The compressor MAY use a 7-bit mask, even if the reference list has more than seven items, provided that changes to the list are only applied to items within the first seven items of the reference list, leaving items with an index not covered by the 7-bit mask unchanged. The decompressor MUST NOT modify items with an index not covered by the 7-bit mask, when a 7-bit mask is received for a reference list that contains more than seven items.
リストの変更が参照リストの最初の7つの項目内のアイテムにのみ適用されている場合、コンプレッサーは7ビットマスクを使用する場合があります。7ビットマスクは変更されていません。減圧装置は、7ビットマスクでカバーされていないインデックスを使用してアイテムを変更してはなりません。7ビットマスクが7ビットマスクを受信して、7つ以上のアイテムを含むリファレンスリストを受信します。
In RFC 3095-Section 5.8, it states that headers that can be part of extension header chains "include" AH [14], ESP NULL [13], minimal encapsulation (MINE) [15], GRE [16][17], and IPv6 [9] extensions. This list of headers that can be compressed is correct, but the word "include" should not be there, since only the header types listed can actually be handled. It should further be noted that for the Minimal Encapsulation (MINE) header, there is no explicit discussion of how to compress it, as the header is sent either uncompressed or fully compressed away.
RFC 3095-Section 5.8では、拡張ヘッダーチェーンの一部になる可能性のあるヘッダーは「AH [14]、ESP Null [13]、Minimal Cankapstulation（Mine）[15]、GRE [16] [17]、およびIPv6 [9]拡張機能。圧縮できるこのヘッダーのリストは正しいですが、「含まれる」という言葉は、実際にはリストされているヘッダータイプのみを処理できるため、そこにあるべきではありません。さらに、最小限のカプセル化（鉱山）ヘッダーの場合、ヘッダーが圧縮されていないか、完全に圧縮されて送られているため、それを圧縮する方法についての明示的な議論はないことに注意してください。
Due to the offset of the fields in the trailer part of the ESP header, a compressor MUST NOT compress packets containing more than one NULL ESP [13] header, unless the second-outermost header is treated as a regular ESP [12] header and the packets are compressed using profile 0x0003.
ESPヘッダーのトレーラー部分のフィールドのオフセットにより、コンプレッサーは、2番目の最大ヘッダーが通常のESP [12]ヘッダーとして扱われない限り、複数のnull esp [13]ヘッダーを含むパケットを圧縮してはなりません。パケットは、プロファイル0x0003を使用して圧縮されます。
RFC 3095-Section 5.8.4 describes how list indexes are associated to list items and how table lists are built for IP extension headers. The text incorrectly states that one index per type is used, since the same type can appear several times with different content in one single chain.
RFC 3095-Section 5.8.4は、リストインデックスがリストアイテムのリストに関連付けられている方法と、IP拡張ヘッダー用のテーブルリストの構築方法を説明しています。テキストは、1つのチェーンで異なるコンテンツで同じタイプが数回表示される可能性があるため、タイプごとに1つのインデックスが使用されることを誤って述べています。
In IP extension header list compression, an index is associated with each individual extension header of an extension header chain. When there are multiple non-identical occurrences of the same extension type (Protocol Number) within a header chain, each MUST be given its own index.
IP拡張ヘッダーリスト圧縮では、インデックスは、拡張ヘッダーチェーンの個々の拡張ヘッダーに関連付けられています。ヘッダーチェーン内に同じ拡張タイプ（プロトコル番号）の複数の非同一の発生がある場合、それぞれに独自のインデックスを与える必要があります。
In the case where there are multiple identical occurrences of the same extension type, the compressor can associate them to the same index. When the value of an item whose index occurs more than once in the list is updated, the compressor MUST send the value for each occurrence of that index in the list.
同じ拡張タイプの複数の同一の発生がある場合、コンプレッサーはそれらを同じインデックスに関連付けることができます。リスト内のインデックスが複数回発生したアイテムの値が更新された場合、コンプレッサーはリスト内のインデックスの各発生の値を送信する必要があります。
When content of extension headers changes, an implementation can choose to either use a different index or update the existing one. Some extensions can be compressed away even when some fields change, as those changes can be conveyed to the decompressor implicitly (e.g. sequence numbers in extension headers that can be inferred from the RTP SN) or explicitly (e.g., as part of the 'IP extension header(s)' field in Extension 3).
拡張ヘッダーのコンテンツが変更されると、実装は別のインデックスを使用するか、既存のインデックスを更新するかを選択できます。一部の拡張機能は、一部のフィールドが変更された場合でも圧縮されます。これらの変更は、それらの変更を暗黙的に（たとえば、RTP SNから推測できる拡張ヘッダーのシーケンス番号）または明示的に（例えば、「IP拡張）ヘッダー 'フィールドのフィールド3）。
When there is more than one IP header, there is more than one list of extension headers, and a translation table is maintained for each list independently of one another.
複数のIPヘッダーがある場合、拡張ヘッダーには複数のリストがあり、互いに独立して各リストに翻訳テーブルが維持されます。
A list compressed using encoding type 1 (insertion), type 2 (removal), or type 3 (removal/insertion) uses a coding scheme that is based on the use of a reference list in the context (identified as ref_id).
エンコーディングタイプ1（挿入）、タイプ2（削除）、またはタイプ3（削除/挿入）を使用して圧縮されたリストは、コンテキストでの参照リストの使用（REF_IDとして識別）に基づくコーディングスキームを使用します。
While it could seem to be a fair choice to send a type 1 list when ref_id is an empty list, there is nothing gained in doing so with respect to using a type 0 list. Sending a type 2 list when ref_id is an empty list would lead to a failure, while sending a type 3 list has very little meaning. All these alternatives could be seen as possible, based on how list compression is specified in RFC 3095.
ref_idが空のリストである場合、タイプ1のリストを送信するのは公正な選択肢であるように思われるかもしれませんが、タイプ0リストの使用に関しては何も得られません。ref_idが空のリストである場合にタイプ2リストを送信すると失敗につながりますが、タイプ3のリストを送信することはほとんど意味がありません。RFC 3095でリスト圧縮がどのように指定されているかに基づいて、これらすべての選択肢は可能な限り見ることができます。
If these alternatives were allowed, a decompressor would become required to maintain a sliding window of ref_id lists in R-mode, even for the case where no items are sent in the compressed list, and this is not a desirable requirement. Using list encoding type 1, type 2, and type 3 is therefore only allowed for non-empty reference lists.
これらの代替案が許可されている場合、圧縮リストにアイテムが送信されない場合でも、Ref_IDリストのスライディングウィンドウをR-Modeで維持する必要があり、これは望ましい要件ではありません。したがって、タイプ1、タイプ2、およびタイプ3のリストエンコードを使用すると、空の参照リストでのみ許可されます。
FORMAL ADDITION TO RFC 3095:
RFC 3095への正式な追加：
"Regardless of the operating mode, for list encoding of type 1, type 2, and type 3 lists, ref_id MUST refer to a non-empty list."
「操作モードに関係なく、タイプ1、タイプ2、およびタイプ3のリストをエンコードするリストの場合、REF_IDは空でないリストを参照する必要があります。」
RFC 3095-Section 5.8.4.2 and RFC 3095-Section 5.8.4.4 describe how to compress the Authentication Header (AH) [14] and the Generic Routing Encapsulation (GRE) [16][17] header. Both these sections present a possibility to omit the AH/GRE sequence number in the compressed header, under certain circumstances. However, the specific conditions for omitting the AH/GRE sequence number, as well as the concrete compression and decompression procedures to apply, are not clearly defined to guarantee robustness and facilitate interoperable implementation.
RFC 3095-Section 5.8.4.2およびRFC 3095-Section 5.8.4.4認証ヘッダー（AH）[14]および汎用ルーティングカプセル化（GRE）[16] [17]ヘッダーを圧縮する方法について説明します。これらのセクションは両方とも、特定の状況下で、圧縮ヘッダーにAH/GREシーケンス番号を省略する可能性を示しています。ただし、AH/GREシーケンス番号を省略するための特定の条件、および適用する具体的な圧縮および減圧手順は、堅牢性を保証し、相互運用可能な実装を促進するために明確に定義されていません。
Proper rules are provided for the ESP case, i.e.,:
ESPケースには適切なルールが提供されています。
"Sequence Number: Not sent when the offset from the sequence number of the compressed header is constant, when the compressor has confidence that the decompressor has established the correct offset. When the offset is not constant, the sequence number may be compressed by sending LSBs"
「シーケンス番号：圧縮ヘッダーのシーケンス番号からのオフセットが一定である場合、コンプレッサーが減圧器が正しいオフセットを確立したと確信している場合、送信されません。オフセットが一定でない場合、LSBSを送信することでシーケンス番号を圧縮することができます。「
The same logic applies to the AH/GRE sequence numbers.
同じロジックがAH/GREシーケンス番号に適用されます。
INCORRECT RFC 3095 TEXT (RFC 3095-Section 5.8.4.2):
誤ったRFC 3095テキスト（RFC 3095-Section 5.8.4.2）：
"If the sequence number in the AH linearly increases as the RTP Sequence Number increases, and the compressor is confident that the decompressor has obtained the pattern, the sequence number in AH need not be sent. The decompressor applies linear extrapolation to reconstruct the sequence number in the AH."
「AHのシーケンス数がRTPシーケンス数が増加すると直線的に増加し、コンプレッサーが減圧器がパターンを取得したと確信している場合、AHのシーケンス番号を送信する必要はありません。ああ。」
CORRECTED TEXT:
修正されたテキスト：
"The AH sequence number can be omitted from the compressed header when the offset from the sequence number (SN) of the compressed header is constant, when the compressor has confidence that the decompressor has established the correct offset."
「圧縮ヘッダーのシーケンス番号（SN）からのオフセットが一定である場合、コンプレッサーが減圧装置が正しいオフセットを確立したという自信がある場合、AHシーケンス数は圧縮ヘッダーから省略できます。」
INCORRECT RFC 3095 TEXT (RFC 3095-Section 5.8.4.4):
誤ったRFC 3095テキスト（RFC 3095-Section 5.8.4.4）：
"If the sequence number in the GRE header linearly increases as the RTP Sequence Number increases and the compressor is confident that the decompressor has received the pattern, the sequence number in GRE need not be sent. The decompressor applies linear extrapolation to reconstruct the sequence number in the GRE header."
「RTPシーケンス数が増加するとGREヘッダーのシーケンス数が直線的に増加し、コンプレッサーが減圧器がパターンを受信したと確信している場合、GREのシーケンス番号を送信する必要はありません。GREヘッダーで。」
CORRECTED TEXT:
修正されたテキスト：
"The GRE sequence number can be omitted from the compressed header when the offset from the sequence number (SN) of the compressed header is constant, when the compressor has confidence that the decompressor has established the correct offset."
「圧縮ヘッダーのシーケンス番号（SN）からのオフセットが一定である場合、コンプレッサーが減圧装置が正しいオフセットを確立したという自信がある場合、GREシーケンス数は圧縮ヘッダーから省略できます。」
A context updating packet that contains compressed sequence number information may also carry information about other fields; in such cases, these fields are updated according to the content of the packet. The updating packet also implicitly updates inferred fields (e.g., RTP Timestamp) according to the current mode and the appropriate mapping function of the updated and inferred fields.
圧縮されたシーケンス番号情報を含むパケットを更新するコンテキストは、他のフィールドに関する情報も伝える場合があります。そのような場合、これらのフィールドはパケットのコンテンツに従って更新されます。更新パケットは、現在のモードと更新および推定されたフィールドの適切なマッピング関数に従って、推定されたフィールド（RTPタイムスタンプなど）を暗黙的に更新します。
An updating packet thus updates the reference values of all header fields, either explicitly or implicitly, except for the UO-1-ID packet (see Section 6.2 of this document). In UO-mode, all packets are updating packets, while in R-mode, all packets with a CRC are updating packets.
したがって、更新パケットは、UO-1-IDパケットを除き、明示的または暗黙的にすべてのヘッダーフィールドの参照値を更新します（このドキュメントのセクション6.2を参照）。UO-Modeでは、すべてのパケットがパケットを更新していますが、Rモードでは、CRCを持つすべてのパケットがパケットを更新しています。
For example, a UO-0 packet contains the compressed RTP sequence number (SN). Such a packet also implicitly updates RTP timestamp, IPv4 ID, and sequence numbers of IP extension headers.
たとえば、UO-0パケットには、圧縮されたRTPシーケンス番号（SN）が含まれています。このようなパケットは、RTPタイムスタンプ、IPv4 ID、およびIP拡張ヘッダーのシーケンス番号を暗黙的に更新します。
RFC 3095-Section 5.7.3 states that the values provided in extensions carried by a UO-1-ID packet do not update the context, except for SN, TS, or IP-ID fields. However, RFC 3095-Section 5.8.1 correctly states that the translation table in the context is updated whenever an (Index, item) pair is received, something that is contradicted by the statement in RFC 3095-5.7.3 because the UO-1-ID packet can carry Extension 3 with (Index, item) pair items within the 'Compressed CSRC list' field. In addition to this contradiction, the text does not mention what to do with the other sequence numbers inferred from the SN, which are also to be implicitly updated. The updating properties of UO-1* as stated by RFC 3095-Section 5.7.3 are thus incomplete.
RFC 3095-Section 5.7.3は、UO-1-IDパケットによって運ばれる拡張機能で提供される値は、SN、TS、またはIP-IDフィールドを除き、コンテキストを更新しないことを示しています。ただし、RFC 3095セクション5.8.1は、（インデックス、アイテム）ペアが受信されるたびにコンテキストの翻訳テーブルが更新されることを正しく述べています。-idパケットは、「圧縮CSRCリスト」フィールド内に（インデックス、アイテム）ペアアイテムを備えた拡張機能3を運ぶことができます。この矛盾に加えて、テキストは、暗黙的に更新されるSNから推測される他のシーケンス番号をどうするかについて言及していません。したがって、RFC 3095セクション5.7.3で述べられているように、UO-1*の更新プロパティは不完全です。
INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7.3):
不完全なRFC 3095テキスト（RFC 3095-Section 5.7.3）：
"Values provided in extensions, except those in other SN, TS, or IP-ID fields, do not update the context."
「他のSN、TS、またはIP-IDフィールドを除く拡張機能で提供される値は、コンテキストを更新しません。」
CORRECTED TEXT:
修正されたテキスト：
"UO-1-ID packets only updates TS, SN, IP-ID, and sequence numbers of IP extension headers. Other values provided in extensions do not update the context.
「UO-1-IDパケットは、IP拡張ヘッダーのTS、SN、IP-ID、およびシーケンス番号のみを更新します。拡張機能で提供されるその他の値は、コンテキストを更新しません。
The decompressor MUST update its translation table whenever an (Index, item) pair is received, as per RFC 3095-Section 5.8.1, and this rule applies also to UO-1-ID packets."
dedypompressorは、RFC 3095-Section 5.8.1に従って（インデックス、アイテム）ペアが受信されるたびに翻訳テーブルを更新する必要があり、このルールはUO-1-IDパケットにも適用されます。」
IR packets do not clear the whole context, but update all fields carried in the IR header. Similarly, an IR without a dynamic chain simply updates the static part of the context, while the rest of the context is left unchanged.
IRパケットはコンテキスト全体をクリアしませんが、IRヘッダーに運ばれるすべてのフィールドを更新します。同様に、動的チェーンのないIRは、コンテキストの静的部分を単純に更新しますが、残りのコンテキストは変更されません。
A consequence of this is that fields that are not updated by the IR packet, e.g., the translation tables for list compression, MUST NOT be invalidated by the decompressor when it assumes context damage.
この結果、IRパケットによって更新されないフィールド、たとえばリスト圧縮のための翻訳表は、コンテキストの損傷を想定したときに減圧器によって無効にされないことです。
RFC 3095-Section 5.7.5 defines the properties of RTP header flags and fields in Extension 3. These get updated when the rtp flag of the Extension 3 is set, i.e., when rtp = 1; otherwise, they are not updated. However, it is unclear how Extension 3 updates the R-P bit in the context.
RFC 3095-Section 5.7.5は、拡張3のRTPヘッダーフラグとフィールドのプロパティを定義します。それ以外の場合、それらは更新されません。ただし、拡張機能がコンテキストでR-Pビットをどのように更新するかは不明です。
INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7.5):
不完全なRFC 3095テキスト（RFC 3095-Section 5.7.5）：
"R-P: RTP Padding bit, absolute value (presumed zero if absent)."
「R-P：RTPパディングビット、絶対値（不在の場合はゼロと推定）。」
CORRECTED TEXT:
修正されたテキスト：
"R-P: RTP Padding bit. If R-PT = 1, R-P is the absolute value of
the RTP padding bit and this value updates context(R-P). If
R-PT = 0, context(R-P) is updated to zero."
RFC 3095-Section 5.7.7.6 defines the properties of the RTP header flags and fields in the RTP part of the dynamic chain of IR and IR-DYN packets. However, it is unclear how the X bit is updated in the context.
RFC 3095-Section 5.7.7.6は、IRおよびIR-Dynパケットの動的チェーンのRTP部分にあるRTPヘッダーフラグとフィールドのプロパティを定義します。ただし、Xビットがコンテキストでどのように更新されるかは不明です。
INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7.7.6):
不完全なRFC 3095テキスト（RFC 3095-Section 5.7.7.6）：
"X: Copy of X bit from RTP header (presumed 0 if RX = 0)"
「X：rtpヘッダーからxビットのコピー（rx = 0の場合は0）」」
CORRECTED TEXT:
修正されたテキスト：
"X: X bit from RTP header. If RX = 1, X is the X bit from the RTP
header and this value updates context(X). If RX = 0,
context(X) is updated to zero."
As part of the negotiated channel parameters, compressor and decompressor have, through the MAX_CID parameter, agreed on the highest context identification (CID) number to be used. By agreeing on MAX_CID, the decompressor also agrees to provide memory resources to host at least MAX_CID+1 contexts, and an established context with a CID within this negotiated space MUST be kept by the decompressor until either the CID gets reused, or the channel is taken down or renegotiated.
ネゴシエートされたチャネルパラメーターの一部として、コンプレッサーと分解器は、MAX_CIDパラメーターを介して、使用する最高のコンテキスト識別（CID）数に合意しました。MAX_CIDに同意することにより、減圧装置は少なくともMAX_CID 1コンテキストをホストするためのメモリリソースを提供することに同意し、このネゴシエートスペース内のCIDを使用した確立されたコンテキストは、CIDが再利用されるか、チャネルが使用されるまで減圧器によって保持する必要がありますダウンまたは再交渉。
As part of the channel negotiation, the maximal number of active contexts supported is negotiated between the compressor and the decompressor through the MAX_CID parameter. The value of MAX_CID can differ significantly from one link application to another, as well as the load in terms of the number of packet streams to compress. The lifetime of a ROHC channel can also vary, from almost permanent to rather short-lived. However, in general, it is not expected that resources will be allocated for more contexts than what can reasonably be expected to be active concurrently over the link. As a consequence hereof, context identifiers (CIDs) and context memory are resources that will have to be reused by the compressor as part of what can be considered normal operation.
チャネル交渉の一環として、サポートされるアクティブコンテキストの最大数は、MAX_CIDパラメーターを介してコンプレッサーと減圧器との間で交渉されます。MAX_CIDの値は、リンクアプリケーションから別のリンクへのアプリケーションと、圧縮するパケットストリームの数の点で負荷を大きく異なる場合があります。ROHCチャネルの寿命も、ほぼ永続的なものからかなり短命までさまざまです。ただし、一般に、リンクを介して同時にアクティブになると合理的に予想されるものよりも、より多くのコンテキストにリソースが割り当てられることは予想されません。結果として、この結果、コンテキスト識別子（CID）とコンテキストメモリは、通常の操作と見なすことができるものの一部としてコンプレッサーが再利用する必要があるリソースです。
How context resources are reused is left unspecified in RFC 3095 [1] and subsequent 3095-based ROHC specifications. This document does not intend to change that, i.e., ROHC resource management is still considered an implementation detail. However, reusing a CID and its allocated memory is not always as simple as initiating a context with a previously unused CID. Because some profiles can be operating in various modes where packet formats vary depending on current mode, care has to be taken to ensure that the old context data will be completely and safely overwritten, eliminating the risk of undesired side effects from interactions between old and new context data. This document therefore points out some important core aspects to consider when implementing resource management in ROHC compressors and decompressors.
コンテキストリソースの再利用方法は、RFC 3095 [1]およびその後の3095ベースのROHC仕様で不特定のままになります。このドキュメントは、それを変更するつもりはありません。つまり、ROHCリソース管理は依然として実装の詳細と見なされます。ただし、CIDとその割り当てられたメモリを再利用することは、以前に使用されていないCIDでコンテキストを開始するほど簡単ではありません。一部のプロファイルは、パケット形式が現在のモードによって異なるさまざまなモードで動作する可能性があるため、古いコンテキストデータが完全かつ安全に上書きされるように注意する必要があり、古いものと新しい間の相互作用による望ましくない副作用のリスクを排除するために注意する必要があります。コンテキストデータ。したがって、このドキュメントは、ROHCコンプレッサーと減圧装置にリソース管理を実装する際に考慮すべき重要なコア側面をいくつか示しています。
On a high level, CID/context reuse can be of two kinds, either reuse for a new context based on the same profile as the old context, or for a new context based on a different profile. These cases are discussed separately in the following two sub-sections.
高レベルでは、CID/コンテキストの再利用は、古いコンテキストと同じプロファイルに基づく新しいコンテキストの再利用、または異なるプロファイルに基づく新しいコンテキストのいずれかの2種類のものになります。これらのケースは、次の2つのサブセクションで個別に説明されています。
For multi-mode profiles, such as those defined in RFC 3095 [1], mode transitions are performed using a decompressor-initiated handshake procedure, as defined in RFC 3095-Section 5.6. When a CID/context is reused for a new context based on the same profile as the old context, the current mode of operation SHOULD be inherited from the old to the new context. Specifically, the compressor SHOULD continue to operate using the mode of operation of the old context also with the new context. The reason for this is that there is no reliable way for the compressor to inform the decompressor that a CID/context reuse is happening. The decompressor can thus not be expected to clear the context memory for the CID (see Section 6.3), and there is no way to trigger a safe mode switching (which requires the decompressor-initiated handshake procedure).
RFC 3095 [1]で定義されているものなどのマルチモードプロファイルの場合、RFC 3095-Section 5.6で定義されているように、減圧装置が開始したハンドシェイク手順を使用してモード遷移が実行されます。CID/コンテキストが古いコンテキストと同じプロファイルに基づいて新しいコンテキストのために再利用される場合、現在の操作モードは古いコンテキストから新しいコンテキストに継承する必要があります。具体的には、コンプレッサーは、新しいコンテキストでも古いコンテキストの動作モードを使用して動作し続ける必要があります。この理由は、コンプレッサーがCID/コンテキストの再利用が発生していることを減圧器に通知する信頼できる方法がないためです。したがって、減圧装置はCIDのコンテキストメモリをクリアすることは期待できません（セクション6.3を参照）。セーフモードの切り替えをトリガーする方法はありません（減圧装置が開始したハンドシェイク手順が必要です）。
The rule of mode inheritance applies also when the CONTEXT_REINITIALIZATION signal (RFC 3095-Section 6.3.1) is used to reinitiate an entire context.
モード継承ルールは、コンテキスト_reinitialization信号（RFC 3095-section 6.3.1）を使用してコンテキスト全体を再現する場合にも適用されます。
When a CID is reused for a new context based on a different profile than the old context, both the compressor and the decompressor MUST start operation with that context in the initial mode of the profile (if it is a multi-mode profile). This applies both to IR-initiated new contexts and profile downgrades with IR-DYN (e.g., the profile 0x0001 -> profile 0x0002 downgrade in RFC 3095-Section 5.11.1).
古いコンテキストとは異なるプロファイルに基づいてCIDが新しいコンテキストで再利用される場合、コンプレッサーと分解器の両方は、プロファイルの初期モードでそのコンテキストで操作を開始する必要があります（マルチモードプロファイルの場合）。これは、IR-Dynを使用したIRが開始した新しいコンテキストとプロファイルの格下げの両方に適用されます（たとえば、RFC 3095-Section 5.11.1のプロファイル0x0001->プロファイル0x0002ダウングレード）。
Type 0 and type 1 packets have different formats in U/O- and R-mode, and these R-mode packets have no CRC. When initiating a new context on a reused R-mode CID, there is a risk that the decompressor will misinterpret compressed packets if the initiating IR packets are lost.
タイプ0とタイプ1のパケットには、u/o-modeとr-modeに異なる形式があり、これらのRモードパケットにはCRCがありません。再利用されたRモードCIDで新しいコンテキストを開始するとき、開始IRパケットが失われた場合、減圧装置が圧縮パケットを誤って解釈するリスクがあります。
A CID for a context currently operating in R-mode SHOULD therefore not be reused for a new context based on a different profile than the old context. A compressor doing otherwise should minimize the risk for misinterpretation of R-0/R-1 by, e.g., not using packets of types beginning with 00 or 10 before it is highly confident that the new context has successfully been initiated at the decompressor.
したがって、Rモードで現在動作しているコンテキストのCIDは、古いコンテキストとは異なるプロファイルに基づいて新しいコンテキストに再利用しないでください。他の方法で行うコンプレッサーは、たとえば、00または10で始まるタイプのパケットを使用しない前に、新しいコンテキストが減圧器で正常に開始されたことを非常に確信することによって、R-0/R-1の誤解のリスクを最小限に抑える必要があります。
In IPv4 dynamic part (RFC 3095-Section 5.7.7.4), if the 'NBO' bit is set, it means that network byte order is used.
IPv4動的部品（RFC 3095-Section 5.7.7.4）では、「NBO」ビットが設定されている場合、ネットワークバイトの順序が使用されることを意味します。
According to RFC 3095-Section 5.7, IP-ID means the compressed value of the IPv4 header's 'Identification' field. Compressed packets contain this compressed value (IP-ID), while IR packets with dynamic chain and IR-DYN packets transmit the original, uncompressed Identification field value. The IP-ID field always represents the Identification value of the innermost IPv4 header whose corresponding RND flag is not 1.
RFC 3095-Section 5.7によると、IP-IDとは、IPv4ヘッダーの「識別」フィールドの圧縮値を意味します。圧縮パケットにはこの圧縮値（IP-ID）が含まれていますが、動的チェーンとIR-Dynパケットを備えたIRパケットは、元の非圧縮識別フィールド値を送信します。IP-IDフィールドは、対応するRNDフラグが1ではない最も内側のIPv4ヘッダーの識別値を常に表します。
If RND or RND2 is set to 1, the corresponding IP-ID(s) is (are) sent as 16-bit uncompressed Identification value(s) at the end of the compressed base header, according to the IP-ID description (see the beginning of RFC 3095-Section 5.7). When there is no compressed IP-ID, i.e., for IPv6 or when all IP Identification information is sent as is (as indicated by RND/RND2 being set to 1), the decompressor ignores IP-ID bits sent within compressed base headers.
RNDまたはRND2が1に設定されている場合、対応するIP-IDは、IP-IDの説明に従って、圧縮ベースヘッダーの最後に16ビットの非圧縮識別値として送信されます（参照RFC 3095-Section 5.7の始まり）。圧縮されたIP-IDがない場合、つまりIPv6の場合、またはすべてのIP識別情報がそのまま送信される場合（RND/RND2が1に設定されていることを示すように）、減圧器は圧縮ベースヘッダー内で送信されるIP-IDビットを無視します。
When RND=RND2=0, IP-ID is compressed, i.e., expressed as an SN offset and byte-swapped if NBO=0. This is the case also when 16 bits of IP-ID is sent in Extension 3.
rnd = rnd2 = 0の場合、IP-idは圧縮されます。つまり、nbo = 0の場合はSNオフセットとバイトスワップとして表されます。これは、16ビットのIP-IDが拡張3で送信される場合にも当てはまります。
When RND=0 but no IP-ID bits are sent in the compressed header, the SN offset for IP-ID stays unchanged, meaning that Offset_m equals Offset_ref, as described in Section 4.5.5. This is further expressed in a slightly different way (with the same meaning) in Section 5.7, where it is said that "default-slope(IP-ID offset) = 0", meaning, if no bits are sent for IP-ID, its SN offset slope defaults to 0.
RND = 0が圧縮ヘッダーにIP-IDビットが送信されない場合、セクション4.5.5で説明されているように、OFFSET_Mは変更されずに、OFFSET_MがOffSet_Refに等しいことを意味します。これはさらに、セクション5.7のわずかに異なる方法（同じ意味を持つ）で表現されます。この場合、「デフォルトスロープ（IP-IDオフセット）= 0」と言われています。つまり、IP-IDにビットが送信されない場合、SNオフセットスロープはデフォルト0になります。
Some flags of the IP header in the extension (e.g., NBO or RND) may change the interpretation of fields in UOR-2* packets. In such cases, when a flag changes in Extension 3, a decompressor MUST re-parse the UOR-2* packet.
拡張機能内のIPヘッダーのフラグ（NBOやRNDなど）は、UOR-2*パケットのフィールドの解釈を変更する場合があります。そのような場合、拡張機能3でフラグが変化する場合、減圧器はUOR-2*パケットを再配分する必要があります。
The RTP header part of Extension 3, as defined by RFC 3095-Section 5.7.5, includes a one-bit field for the RTP Marker bit. This field is also present in all compressed base header formats except for UO-1-ID; meaning, there may be two occurrences of the field within one single compressed header. In such cases, the two M fields must have the same value.
RFC 3095-Section 5.7.5で定義されている拡張機能3のRTPヘッダー部分には、RTPマーカービットの1ビットフィールドが含まれています。このフィールドは、UO-1-IDを除くすべての圧縮ベースヘッダー形式にも存在します。つまり、単一の圧縮ヘッダー内にフィールドの2つの発生がある場合があります。そのような場合、2つのMフィールドに同じ値が必要です。
FORMAL ADDITION TO RFC 3095:
RFC 3095への正式な追加：
"When there are two occurrences of the M field in a compressed header (both in the compressed base header and in the RTP part of Extension 3), the compressor MUST set both these occurrences of the M field to the same value.
「圧縮ヘッダー（圧縮ベースヘッダーと拡張3のRTP部分の両方）にMフィールドの2つの発生がある場合、コンプレッサーはMフィールドのこれらの両方の発生を同じ値に設定する必要があります。
At the decompressor, if the two M field values of such a packet are not identical, the packet MUST be discarded."
減圧器では、このようなパケットの2つのMフィールド値が同一でない場合、パケットを破棄する必要があります。」
The length of the sequence number field in the original ESP [12] header is 32 bits. The format of the SN feedback option (RFC 3095- Section 5.7.6.6) allows for 8 additional SN bits to the 12 SN bits of the FEEDBACK-2 format (RFC 3095-Section 5.7.6.1). One single SN feedback option is thus not enough for the decompressor to send back all the 32 bits of the ESP sequence number in a feedback packet, unless it uses multiple SN options in one feedback packet.
元のESP [12]ヘッダーのシーケンス番号フィールドの長さは32ビットです。SNフィードバックオプション（RFC 3095-セクション5.7.6.6）の形式では、フィードバック-2形式の12 SNビット（RFC 3095セクション5.7.6.1）に8追加のSNビットが可能になります。したがって、1つのSNフィードバックオプションでは、1つのフィードバックパケットで複数のSNオプションを使用しない限り、フィードバックパケットでESPシーケンス番号の32ビットすべてをすべて送信するには、1つのSNフィードバックオプションでは十分ではありません。
RFC 3095-Section 5.7.6.1 declares that a FEEDBACK-2 packet can contain a variable number of feedback options, and the options can appear in any order.
RFC 3095-section 5.7.6.1は、フィードバック2パケットに変数数のフィードバックオプションを含めることができ、オプションが任意の順序で表示できることを宣言します。
When processing multiple SN options in one feedback packet, the SN would be given by concatenating the fields.
1つのフィードバックパケットで複数のSNオプションを処理する場合、SNはフィールドを連結することにより指定されます。
Although it is not useful to have more than one single CRC option in a feedback packet, having multiple CRC options is still allowed. If multiple CRC options are included, all such CRC options MUST be identical, as they will be calculated over the same header; the compressor MUST otherwise discard the feedback packet.
フィードバックパケットに複数のCRCオプションを使用すると便利ではありませんが、複数のCRCオプションを持つことはまだ許可されています。複数のCRCオプションが含まれている場合、同じヘッダーで計算されるため、そのようなCRCオプションはすべて同一でなければなりません。そうでなければ、コンプレッサーはフィードバックパケットを破棄する必要があります。
Although this is neither desirable or expected, it may happen that a link used to carry feedback between two associated instances becomes unavailable. If the compressor can be notified of such an event, the compressor SHOULD restart compression for each flow that is operating in R-mode. When restarting compression, the compressor SHOULD use a different CID for each flow being restarted; this is useful to avoid the possibility of misinterpreting the type of the compressed header for the packet type identifiers that are common to both U/O-mode and R-mode, when the flow is restarted in U-mode (see also Section 7.2).
これは望ましくも予想もありませんが、2つの関連するインスタンスの間にフィードバックを運ぶために使用されるリンクが利用できなくなることがあります。コンプレッサーにそのようなイベントを通知できる場合、コンプレッサーはRモードで動作している各フローの圧縮を再起動する必要があります。圧縮を再起動するとき、コンプレッサーは再起動する各フローに異なるCIDを使用する必要があります。これは、Uモードでフローが再起動されたときに、U/OモードとRモードの両方に共通するパケットタイプの識別子の圧縮ヘッダーのタイプを誤って解釈する可能性を回避するのに役立ちます（セクション7.2も参照）。
Generally, feedback links are not expected to disappear once present, but it should be noted that this might be the case for certain link technologies.
一般に、フィードバックリンクは存在すると消えるとは予想されませんが、特定のリンクテクノロジーの場合には当てはまる可能性があることに注意する必要があります。
One single new format is defined for UOR-2 in profile 0x0002 and profile 0x0003, which replaces all three (UOR-2, UOR-2-ID, UOR-2-TS) formats from profile 0x0001. The same UOR-2 format is thus used independent of whether or not there are IP headers with a corresponding RND=1. This also applies to the IP profile [4] and the IP/UDP-Lite profile [5].
プロファイル0x0002とプロファイル0x0003のUOR-2に対して1つの新しい形式が定義されています。これは、プロファイル0x0001の3つすべて（UOR-2、UOR-2-ID、UOR-2-TS）形式を置き換えます。したがって、同じUOR-2形式は、対応するRND = 1のIPヘッダーがあるかどうかとは無関係に使用されます。これは、IPプロファイル[4]およびIP/UDP-Liteプロファイル[5]にも適用されます。
In RFC 3095-Section 5.8.5, formats are defined for compression of IP extension header fields. These include compressed sequence number fields, and these fields contain the "LSB of sequence number". These sequence numbers are not "LSB-encoded" as, e.g., the RTP sequence number, but are the LSB's of the uncompressed fields.
RFC 3095-Section 5.8.5では、IP拡張ヘッダーフィールドの圧縮のために形式が定義されています。これらには圧縮シーケンス番号フィールドが含まれ、これらのフィールドには「シーケンス番号のLSB」が含まれています。これらのシーケンス番号は、たとえばRTPシーケンス番号として「LSBエンコード」されていませんが、非圧縮フィールドのLSBです。
Usage of UOR-2 ACKs in O-mode, as discussed in RFC 3095-Section 5.4.1.1.2, is optional. A decompressor can also send ACKs for purposes other than to acknowledge the UOR-2, without having to continue sending ACKs for all UOR-2. Similarly, a compressor implementation can ignore UOR-2s ACKs for the purpose of adapting the optimistic approach strategies.
RFC 3095-Section 5.4.1.1.2で説明されているように、O-ModeでのUOR-2 Ackの使用はオプションです。減圧装置は、すべてのUOR-2にACKを送信し続けることなく、UOR-2を認める以外の目的でACKを送信することもできます。同様に、コンプレッサーの実装では、楽観的なアプローチ戦略を適応させる目的で、UOR-2S Acksを無視できます。
It is thus NOT RECOMMENDED to use the optional ACK mechanism in O-mode, either in compressor or in decompressor implementations.
したがって、コンプレッサーまたは減圧装置の実装のいずれかで、OモードでオプションのACKメカニズムを使用することは推奨されません。
Using an incorrect expectation on UOR-2 ACKs as a basis for compressor behavior will significantly degrade the compression performance. This is because UOR-2 ACKs can be sent from a decompressor for other purposes than to acknowledge the UOR-2 packet, e.g., to send feedback such as clock resolution, or to initiate a mode transition. If an implementation does use the optional acknowledgment algorithm described in Section 5.4.1.1.2, it must make sure to set the k_3 and n_3 parameters to much larger values than 1 to ensure that the compressor performance is not degraded due to the problem described above.
コンプレッサーの動作の基礎としてUOR-2 Acksの誤った期待を使用すると、圧縮性能が大幅に低下します。これは、UOR-2 ACKを他の目的のために減圧器から送信することができるためです。たとえば、クロック解像度などのフィードバックを送信したり、モード遷移を開始したりする以外の場合は、他の目的で送信できます。実装がセクション5.4.1.1.2で説明されているオプションの確認アルゴリズムを使用している場合、上記の問題のためにコンプレッサーの性能が低下しないように、K_3およびN_3パラメーターを1よりもはるかに大きな値に設定する必要があります。。
The 7-bit CRC used to verify the outcome of the decompression attempt covers the original uncompressed header. The CRC verification thus excludes TS_STRIDE and TIME_STRIDE, as these fields are not part of the original uncompressed header.
減圧試行の結果を検証するために使用される7ビットCRCは、元の非圧縮ヘッダーをカバーします。したがって、CRC検証はTS_STRIDEとTIME_STRIDEを除外します。これらのフィールドは元の非圧縮ヘッダーの一部ではないためです。
The UOR-2 packet type can be used to update the value of the TS_STRIDE and/or the TIME_STRIDE, with the Extension 3. However, these fields are not used for decompression of the RTP TS field for this packet type and their respective value is thus not verified, either implicitly or explicitly.
UOR-2パケットタイプは、TS_STRIDEおよび/またはTIME_STRIDEの値を更新するために使用できます。したがって、暗黙的または明示的に検証されません。
When the compressor receives a negative acknowledgement, it thus cannot determine whether the failure may be caused by an unsuccessful update to the TS_STRIDE and/or the TIME_STRIDE field(s), for which a previous header that last attempted to update their value had previously been acknowledged.
コンプレッサーが否定的な認識を受信すると、障害がTS_STRIDEおよび/またはTIME_STRIDEフィールドの更新の失敗によって引き起こされる可能性があるかどうかを判断できません。認められた。
FORMAL ADDITION TO RFC 3095:
RFC 3095への正式な追加：
"When the compressor receives a NACK and uses the UOR-2 header type to repair the decompressor context, it SHOULD include fields that update the value of both the TS_STRIDE and the TIME_STRIDE whose value it has updated at least once since the establishment of that context, i.e., since the CID was first associated with its current profile.
「コンプレッサーがNACKを受信し、UOR-2ヘッダータイプを使用して減圧器のコンテキストを修復する場合、TS_STRIDEとTIME_STRIDEの両方の値を更新するフィールドを含める必要があります。、つまり、CIDは最初に現在のプロファイルに関連付けられていたためです。
When the compressor receives a static-NACK, it MUST include in the IR header fields for both the TS_STRIDE and the TIME_STRIDE whose value it has updated at least once since the establishment of that context, i.e., since the CID was first associated with its current profile."
コンプレッサーが静的ナックを受信する場合、TS_STRIDEとTIME_STRIDEの両方のIRヘッダーフィールドに、そのコンテキストの確立以来、つまりCIDが最初に電流に関連付けられていたため、少なくとも1回は更新されたTime_Strideの両方に含める必要があります。プロフィール。"
RFC 3095-Section 4.1 states that the link layer must provide means to negotiate, e.g., the channel parameters listed in RFC 3095-Section 5.1.1. One of these parameters is the PROFILES parameter, which is a set of non-negative integers where each integer indicates a profile supported by the decompressor.
RFC 3095-Section 4.1は、リンクレイヤーがRFC 3095-Section 5.1.1にリストされているチャネルパラメーター、たとえば交渉する手段を提供する必要があると述べています。これらのパラメーターの1つはプロファイルパラメーターです。これは、各整数が減圧器によってサポートされているプロファイルを示す非陰性整数のセットです。
Each profile is identified by a 16-bit value, where the 8 LSB bits indicate the actual profile, and the 8 MSB bits indicate the variant of that profile (see RFC 3095-Section 8). In the ROHC headers sent over the link, the profile used is identified only with the 8 LSB bits, which means that the compressor and decompressor must have agreed on which variant to use for each profile.
各プロファイルは16ビット値で識別され、8 LSBビットは実際のプロファイルを示し、8 MSBビットはそのプロファイルのバリアントを示します（RFC 3095-Section 8を参照）。リンク上に送信されるROHCヘッダーでは、使用されるプロファイルは8 LSBビットでのみ識別されます。つまり、コンプレッサーと減圧装置は、各プロファイルに使用するバリアントに同意している必要があります。
The negotiation protocol must thus be able to communicate to the compressor the set of profiles supported by the decompressor. When multiple variants of the same profile are available, the negotiation protocol must provide the means for the decompressor to know which variant will be used by the compressor. This basically means that the PROFILES set after negotiation MUST NOT include more than one variant of a profile.
したがって、ネゴシエーションプロトコルは、減圧器によってサポートされているプロファイルのセットをコンプレッサーに通信できる必要があります。同じプロファイルの複数のバリアントが利用可能な場合、交渉プロトコルは、圧縮者がコンプレッサーで使用するバリアントを知る手段を提供する必要があります。これは基本的に、交渉後に設定されたプロファイルにプロファイルの複数のバリアントを含めてはならないことを意味します。
The logical union of sub-options for IPCP and IPV6CP negotiations, as specified by ROHC over PPP [2], cannot be used for the PROFILES suboption, as the whole union would then have to be considered within each of the two IPCP negotiations to avoid getting an ambiguous profile set. An implementation of RFC 3241 MUST therefore ensure that the same profile set is negotiated for both IPv4 and IPv6 (IPCP/IPV6CP).
PPPを介してROHCによって指定されているIPCPおよびIPv6CPのネゴシエーションのサブオプションの論理的結合[2]は、プロファイルサブオプションには使用できません。あいまいなプロファイルセットを取得します。したがって、RFC 3241の実装は、同じプロファイルセットがIPv4とIPv6（IPCP/IPv6CP）の両方でネゴシエートされるようにする必要があります。
In the ROHC IP-only profile, Section 3.3 of RFC 3843 [4], a mechanism for encoding of a constant Identification value in IPv4 (constant IP-ID) is defined. This mechanism is also used by the ROHC UDP-Lite profiles, RFC 4019 [5].
ROHC IPのみのプロファイルでは、RFC 3843 [4]のセクション3.3 [4]では、IPv4（定数IP-ID）の定数識別値をエンコードするメカニズムが定義されています。このメカニズムは、ROHC UDP-Liteプロファイル、RFC 4019 [5]によっても使用されています。
The "Constant IP-ID" mechanism applies to both the inner and outer IP header, when present, meaning that there will be both a SID and a SID2 context value.
「定数IP-ID」メカニズムは、存在する場合、内側と外側のIPヘッダーの両方に適用されます。つまり、SIDとSID2コンテキスト値の両方が存在することを意味します。
This document provides a number of corrections and clarifications to [1], but it does not make any changes with regard to the security aspects of the protocol. As a consequence, the security considerations of [1] apply without additions.
このドキュメントは、[1]の多くの修正と明確化を提供しますが、プロトコルのセキュリティの側面に関しては変更を加えません。結果として、[1]のセキュリティ上の考慮事項は、追加せずに適用されます。
The authors would like to thank Vicknesan Ayadurai, Carsten Bormann, Mikael Degermark, Zhigang Liu, Abigail Surtees, Mark West, Tommy Lundemo, Alan Kennington, Remi Pelland, Lajos Zaccomer, Endre Szalai, Mark Kalmanczhelyi, and Arpad Szakacs for their contributions and comments. Thanks also to the committed document reviewers, Carl Knutsson and Biplab Sarkar, who reviewed the document during working group last-call.
著者は、Vicknesan Ayadurai、Carsten Bormann、Mikael Degermark、Zhhigang Liu、Abigail Surtees、Mark West、Tommy Lundemo、Alan Kennington、Remi Pelland、Lajos Zaccomer、Endre Szalai、Mark Kalmanczhelions、およびArpad Szakacs and Arpad Szakacsに感謝します。。コミットされたドキュメントレビュー担当者であるCarl KnutssonとBiplab Sarkarにも感謝します。
[1] 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.
[1] 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、 "Robust Header圧縮（ROHC）：フレームワークと4つのプロファイル：RTP、UDP、ESP、および非圧縮」、RFC 3095、2001年7月。
[2] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
[2] Bormann、C。、「PPP上の堅牢なヘッダー圧縮（ROHC）」、RFC 3241、2002年4月。
[3] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[3] シンプソン、W。、「HDLCのようなフレーミングのPPP」、STD 51、RFC 1662、1994年7月。
[4] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A Compression Profile for IP", RFC 3843, June 2004.
[4] ジョンソン、L-E。およびG. Pelletier、「堅牢なヘッダー圧縮（ROHC）：IPの圧縮プロファイル」、RFC 3843、2004年6月。
[5] Pelletier, G., "RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite", RFC 4019, April 2005.
[5] Pelletier、G。、「堅牢なヘッダー圧縮（ROHC）：ユーザーデータグラムプロトコル（UDP）Liteのプロファイル」、RFC 4019、2005年4月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[7] Jonsson, L-E., Pelletier, G., and K. Sandlund, "RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 4362, January 2006.
[7] Jonsson、L-E。、Pelletier、G。、およびK. Sandlund、「Robust Header Compression（ROHC）：IP/UDP/RTPのリンク層アシストプロファイル」、RFC 4362、2006年1月。
[8] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[8] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[9] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[9] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[10] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[10] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[11] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[11] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[12] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[12] Kent、S。、「セキュリティペイロード（ESP）のカプセル化IP」、RFC 4303、2005年12月。
[13] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[13] Glenn、R。およびS. Kent、「Null暗号化アルゴリズムとIPSECでの使用」、RFC 2410、1998年11月。
[14] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[14] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[15] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[15] Perkins、C。、「IP内の最小カプセル化」、RFC 2004、1996年10月。
[16] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[16] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「一般的なルーティングカプセル化（GRE）」、RFC 2784、2000年3月。
[17] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[17] Dommety、G。、「キーおよびシーケンス番号GREへの拡張」、RFC 2890、2000年9月。
#!/usr/bin/perl -w
use strict;
#=================================
#
# ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02
#
# This little demo shows the four types of CRCs in use in RFC 3095,
# the specification for robust header compression. Type your data in
# hexadecimal form and then press Control+D.
#
#---------------------------------
#
# utility
#
sub dump_bytes($) {
my $x = shift;
my $i;
for ($i = 0; $i < length($x); ) {
printf("%02x ", ord(substr($x, $i, 1)));
printf("\n") if (++$i % 16 == 0);
}
printf("\n") if ($i % 16 != 0);
}
#---------------------------------
#
# The CRC calculation algorithm.
#
sub do_crc($$$) {
my $nbits = shift;
my $poly = shift;
my $string = shift;
my $crc = ($nbits == 32 ? 0xffffffff : (1 << $nbits) - 1);
for (my $i = 0; $i < length($string); ++$i) {
my $byte = ord(substr($string, $i, 1));
for( my $b = 0; $b < 8; $b++ ) {
if (($crc & 1) ^ ($byte & 1)) {
$crc >>= 1;
$crc ^= $poly;
} else {
$crc >>= 1;
}
$byte >>= 1;
}
}
printf "%2d bits, ", $nbits;
printf "CRC: %02x\n", $crc;
}
#---------------------------------
#
# Test harness
#
$/ = undef;
$_ = <>; # read until EOF
my $string = ""; # extract all that looks hex:
s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg;
dump_bytes($string);
#---------------------------------
#
# 32-bit segmentation CRC
# Note that the text implies that this is complemented like for PPP
# (this differs from 8-, 7-, and 3-bit CRCs)
#
# C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 +
# x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32
#
do_crc(32, 0xedb88320, $string);
#---------------------------------
#
# 8-bit IR/IR-DYN CRC
#
# C(x) = x^0 + x^1 + x^2 + x^8
#
do_crc(8, 0xe0, $string);
#---------------------------------
#
# 7-bit FO/SO CRC
#
# C(x) = x^0 + x^1 + x^2 + x^3 + x^6 + x^7
#
do_crc(7, 0x79, $string);
#---------------------------------
#
# 3-bit FO/SO CRC
#
# C(x) = x^0 + x^1 + x^3
#
do_crc(3, 0x6, $string);
Authors' Addresses
著者のアドレス
Lars-Erik Jonsson Optand 737 SE-831 92 Ostersund, Sweden Phone: +46 70 365 20 58 EMail: lars-erik@lejonsson.com
Lars-erik Jonsson Optand 737 SE-831 92 SWEDEN電話：46 70 365 20 58電子メール：lars-erik@lejonsson.com
Kristofer Sandlund Ericsson AB Box 920 SE-971 28 Lulea, Sweden Phone: +46 8 404 41 58 EMail: kristofer.sandlund@ericsson.com
Kristofer Sandlund Ericsson AB Box 920 Se-971 28 Lulea、Sweden電話：46 8 404 41 58メール：kristofer.sandlund@ericsson.com
Ghyslain Pelletier Ericsson AB Box 920 SE-971 28 Lulea, Sweden Phone: +46 8 404 29 43 EMail: ghyslain.pelletier@ericsson.com
Ghyslain Pelletier Ericsson AB Box 920 Se-971 28 Lulea、Sweden電話：46 8 404 29 43電子メール：ghyslain.pelletier@ericsson.com
Peter Kremer Conformance and Software Test Laboratory Ericsson Hungary H-1300 Bp. 3., P.O. Box 107, HUNGARY Phone: +36 1 437 7033 EMail: peter.kremer@ericsson.com
Peter Kremerの適合およびソフトウェアテスト研究所Ericsson Hungary H-1300 bp。3.、P.O。ボックス107、ハンガリー電話：36 1 437 7033メール：peter.kremer@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
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, THE IETF TRUST 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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エディター機能の資金は現在、インターネット協会によって提供されています。