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

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




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
1. Introduction and Terminology

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(リアルタイムトランスポートプロトコル)のためのロバストヘッダ圧縮(ROHC)フレームワークおよびプロファイル[11]定義、および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.

加えて、いくつかの明確化及び訂正は、(PPP上ROHC)[2]、RFC 3843(ROHC IP-プロファイルのみ)RFC 3241のために提供されている[4]、及びRFC 4019(ROHC UDP-Liteのプロファイル)[5]、これこれもこのドキュメントによって更新されます。さらに、RFC 4362(ROHCリンク層支援プロファイル)[7]暗黙的にこの文書により更新されるが、RFC 4362以降も、RFC 3095に基づいています。

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

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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からのテキストが該当する場合、与えられ、「未」「誤った」、または「不正確で無効」とラベル付けされた、「補正」とラベル付けされた正しいテキストが続いています。テキストは、単に正しいテキストは、前の仕様ではないが追加されている場合、それはラベル「FORMAL ADDITION」を与えています。

In this document, a reference to a section in RFC 3095 [1] is written as RFC 3095-Section <number>.

この文書では、RFC 3095でセクションへの参照は、[1] RFC 3095、セクション<番号>のように記述されています。

2. CRC Calculation and Coverage
2. CRC計算とカバレッジ
2.1. CRC Calculation
2.1. CRCの計算

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.


2.2. Padding Octet and CRC Calculations
2.2. パディングオクテットとCRCの計算

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.

それはIRおよびIR-DYNパケットのCRC計算でパディングオクテットを処理する方法に言及していないとして、RFC 3095、セクション5.9.1は、不完全です。パディングは、パケットの意味の一部であることを意味せず、CRC計算に含まれません。その結果、CRCのいずれか、CID 0のAdd-CIDオクテットをカバーしていません。

INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.9.1):

INCOMPLETE RFC 3095 TEXT(RFC 3095-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."




"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のアドインCIDオクテットを除いCIDまたは任意のアドオンCIDオクテットを含む、全体IRまたはIR-DYNパケットにわたって計算されます」

2.3. CRC Coverage in CRC Feedback Options
2.3. CRCフィードバックオプションでCRCカバレッジ

RFC 3095-Section 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.

CRCフィードバックオプションで使用される8ビットのCRCを計算するとき、それは「サイズ」フィールドがどのように扱われるかについて言及していないとして、RFC 3095、セクション5.7.6.3は、不完全です。 「サイズ」フィールドが「コード」フィールドの拡張であるので、同じ方法で処理しなければなりません。

INCOMPLETE RFC 3095 TEXT (RFC 3095-Section

INCOMPLETE RFC 3095 TEXT(RFC 3095 - セクション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."




"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フィールドを含むが、セクション5.9.1の多項式を使用して、パケットタイプ、 『サイズ』フィールドと 『コード』のオクテットを除いた全体フィードバックペイロードにわたって計算8ビットのCRCが含まれています。」

2.4. CRC Coverage of the ESP NULL Header
2.4. ESP NULLヘッダのCRCカバレッジ

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

RFC 3095、セクション5.8.7は、「全体ESPヘッダ」としてESP NULL [13]ヘッダのCRCの適用範囲を与えます。これは、ヘッダ、ペイロードの終わりに(すなわち、セキュリティパラメータインデックス(SPI)とシーケンス番号)、およびいないトレーラ部分のみ初期部分を含むものとして解釈されなければなりません。したがって、ESPのNULLヘッダは、ESPプロファイル(RFC 3095、セクション5.7.7.7)で使用されるESPヘッダと同じCRCカバレッジを有します。

3. Mode Transition
3.1. Feedback During Mode Transition to U- and O-Mode
3.1. U-へのモード遷移とOモード中にフィードバック

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 - セクション5.6.1はD_TRANSパラメータは、私がいる間に、それぞれがパケットを受信するためのモード遷移時に、解凍器は、フィードバックを送信することを述べています。この制限の動作は、モード遷移時のまばらなフィードバックアルゴリズムを使用してからデコンプレッサを防ぐことができます。

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.


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に記載された手順に従って実施減圧装置と相互運用します。

3.1.1. Mode Transition Procedures Allowing Sparse Feedback
3.1.1. スパースフィードバックを許可するモード遷移手続き

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.

これらの拡張遷移手順の目的は、適切なIR / IR-DYN / UOR-2パケットは、圧縮機から受信された後にまばらに減圧装置が、すなわち、遷移手順の後半解凍パケットに対するフィードバックを送信できるようにすることです。これは、セクション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、セクション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)NITIATED、(P)ENDING、及び(D)ONE。 D_TRANSはDに初期化しなければならない、とD_TRANSがDである場合にのみ、モード遷移はD_TRANSがIであるが、減圧装置が受信した各パケットの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に記載の遷移)動作の楽観一方向モードへの遷移に影響を及ぼし、R-する遷移を説明する図を有するもの遷移図は、より一貫性を持たせますモード。

3.1.2. Transition from Reliable to Optimistic Mode
3.1.2. 信頼性から楽観モードへの遷移

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
                  |                               |
3.1.3. Transition to Unidirectional Mode
3.1.3. 単方向モードへの移行

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
3.2. Feedback During Mode Transition
3.2. モード遷移中にフィードバック

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 - セクション5.6.1は、フィードバックは常にモード遷移の際に使用されていると述べています。ただし、テキストはその後のCRCが使用された場合、それは不明で作り、一貫性のない方法で、ルールの具体的なアプリケーションを作ることによって継続します。さらに、テキストは、圧縮機がモード遷移アクションを実行するか否か、のCRC、すなわちによって保護されていないフィードバックに基づいて、モード遷移中に作用する方法を定義していません。コンプレッサーからの適切な動作は、フィードバックがCRCオプションで保護されている唯一のモード遷移に関連する任意のアクションを実行することです。

INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.6.1):

INCOMPLETE RFC 3095 TEXT(RFC 3095 - セクション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."




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

One more related issue that requires clarifications comes from the following text at the end of RFC 3095-Section 5.6.1:

明確化が必要となるもう一つの関連する問題は、RFC 3095、セクション5.6.1の末尾に次のテキストから来ています:

"While D_TRANS is I, the decompressor sends a NACK or ACK carrying a CRC option for each received packet."


However, RFC 3095-Section 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-項では、すでに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 *パケットのシーケンス番号。

3.3. Packet Decoding During Mode Transition
3.3. モード遷移中のパケットのデコード

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.


4. Timestamp Encoding
4.1. Encoding Used for Compressed TS Bits
4.1. 圧縮されたTSのビットのために使用されるエンコーディング

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、セクション4.5.6)を使用して送信され、これはスケーリングおよびスケーリングされていない値の両方に適用されます。

4.2. (De)compression of TS without Transmitted TS Bits
4.2. 透過TSビットなしのTSの(デ)圧縮

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シーケンス番号(SN)ビットが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ビット、スケーリングまたはスケーリングされていないのいずれかに基づいて解凍する方法を定義するが、圧縮ヘッダに存在しないTSビットが存在しない場合、SNから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ビットが圧縮ヘッダで受信されない場合、スケーリングされたTS値は、SNから線形外挿を想定して再構成され、すなわち、delta_TS = delta_SN * delta_SNとdelta_TSの両方の符号付き整数でデフォルトスロープ、。 RFC 3095 - セクション5.7は、デフォルトのスロープのための潜在的な値を定義します。

INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7):

INCOMPLETE RFC 3095 TEXT(RFC 3095 - セクション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)."

値(TSC)= 0の場合、タイムスタンプ値をそのまま圧縮され、デフォルトの傾斜(TS)=値(TS_STRIDE)されています。」



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

「NO TSビットを有する圧縮されたヘッダが受信されると、スケーリングされたTS値は、SNから線形外挿を想定して再構成され、すなわち、delta_TS = delta_SN *デフォルト傾斜(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."

値(TSC)は= 0場合、タイムスタンプ値をそのまま圧縮され、デフォルトスロープ(TS)=値(TS_STRIDE)。無TSビットを有するパケットがTscの= 0で受信された場合、デコンプレッサは、パケットを破棄しなければなりません「。


不正確で無効化されたRFC 3095 TEXT(セクションRFC 3095-

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

Consequently, there is no other slope value than the default-slope, as defined in RFC 3095-Section 5.7.

したがって、RFC 3095、セクション5.7で定義されているデフォルトスロープよりも他の勾配値は、存在しません。

4.3. Interpretation Intervals for TS Encoding
4.3. TSエンコーディングのための通訳間隔

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.


For timer-based compression (TIME_STRIDE set to a non-zero value), the interpretation interval is:


p = 2^(k-1) - 1 (as per RFC 3095-Section 4.5.4)

P = 2 ^(K-1) - 1(RFC 3095、セクション4.5.4によります)

Otherwise, the interpretation interval is:


p = 2^(k-2) - 1 (as per RFC 3095-Section 5.7)

P = 2 ^(K-2) - 1(RFC 3095、セクション5.7によります)

4.4. Scaled RTP Timestamp Encoding
4.4. スケーリングされたRTPタイムスタンプのエンコード

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に記載されています。

4.4.1. TS_STRIDE for Scaled Timestamp Encoding
4.4.1. スケーリングされたタイムスタンプのエンコードのためのTS_STRIDE

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:

RFC 3095 - 4.5.3項に、次の等式によって与えられるTSとTS_SCALEDとの関係は、TS_STRIDEの数学的な意味を定義しています。



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を除外するので、それは定義によって、または上記コア等式によって除外されない代替物である0のTS_STRIDE値を妨げるからです。 「/」は、「xをyで割っからの結果の不可欠な部分」を意味する一般一義的定義された操作であった場合、TS_OFFSETの欠如を説明することができるが、式は依然として0の式に等しいTS_STRIDEのために適切な出力を欠いていることになります「2.圧縮」の唯一の次の要件をこのように有効です。

a) "/" means "the integral part of the result from dividing X by Y"


b) TS_STRIDE>0 (TS is never sent scaled when TS_STRIDE=0)

b)のTS_STRIDEは> 0(TS)が時にTS_STRIDE = 0スケール送信されることはありません

4.4.2. TS Wraparound with Scaled Timestamp Encoding
4.4.2. スケーリングされたタイムスタンプのエンコードとTSラップアラウンド

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.

圧縮機がラップアラウンドでTS_OFFSETを初期化する必要はなく、TSの回り込みがある場合にスケーリングされたTS値のために送信ビット数を増加させるために必要とされるそのされていないことを点4と5でRFC 3095、セクション4.5.3状態。デコンプレッサは、また、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を再初期化しなければなりません。

4.4.3. Algorithm for Scaled Timestamp Encoding
4.4.3. スケーリングされたタイムスタンプ符号化アルゴリズム

INCORRECT RFC 3095 TEXT (RFC 3095-Section 4.5.3):

INCORRECT RFC 3095 TEXT(RFC 3095-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.


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を想定してみましょう。次のRTPのTS =を0x00000130(すなわち、増分が* 2 = 320 160である)場合= 80は次に、新しいTS_OFFSETは0x00000130モジュロ0xA0を= 0x90を= 144、圧縮機の再初期化するために必要とされないれるべきである0x50をTS_OFFSETは次にですラップアラウンドでTS_OFFSET。その代わりに、減圧装置は「TS_OFFSET =(スケーリングされていないTSの周りに包まれた)モジュロTS_STRIDEに(自明で)スケーリングされていないTSの回り込みと更新TS_OFFSETを検出しなければなりません



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

RTP TSスケーリング関数の「1初期化及び更新が:圧縮機は、スケーリングされていないTSと共にデコンプレッサへTS_STRIDE値を送信し、これらは両方HDR(TS)モジュロフィールド(TS_STRIDE)としてTS_OFFSETを初期化するために解凍装置により必要とされる注意。 4を参照)以下、その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.


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_OFFSETとして算出されます。

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



不正確で無効化されたRFC 3095 TEXT(RFC 3095-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解釈間隔」から始まり、「LSBの数としよう」とそれが「で終わるで始まるテキストのブロックを含む、すなわち.. .interpretation間隔はBです。」間違っているため、無効です。

4.5. Recalculating TS_OFFSET
4.5. TS_OFFSETを再計算

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モジュロTS_STRIDE)を再計算しなければなりません。

4.6. TS_STRIDE and the Tsc Flag in Extension 3
4.6. 延長3におけるTS_STRIDEとTscの旗

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がスケーリングされているか否かを示します。何TSビットは拡張自体に存在しない場合のTSCフラグの値は、したがって、すべてのTSビットに適用され、ならびに。 TSがスケーリングされると、それは常にコンテキスト(TS_STRIDE)を使用してスケーリングされます。 RFC 3095、セクション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ビットを運ぶべきです。 Tssとが設定されている場合にスケーリングされていないTSがTS_OFFSETを再計算するTS_STRIDEと共に必要とされるので、すなわちたTSCフラグは設定しないでください。 TS_STRIDEがスケーリングTSと圧縮ヘッダに含まれている場合、デコンプレッサは、(TS_STRIDE)を無視して、フィールドを破棄しなければなりません。

INCORRECT RFC 3095 TEXT (RFC 3095-Section 5.7.5):

INCORRECT RFC 3095 TEXT(RFC 3095 - セクション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."

「Tscの:。TSC = 0 TSがスケーリングされていないことを示し、Tscの= 1は、圧縮機、スケーリングが望まれていない場合は常に1であるTSが(TS_STRIDE)コンテクスト(TSC)値を使用して、セクション4.5.3に従ってスケーリングされることを示しています。 「= 1 TS_STRIDEを確立します



"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は、コンテキスト(TS_STRIDE)を使用して、セクション4.5.3に従ってスケーリングされることを示しています。

            Context(Tsc) is always 1.  If scaling is not desired, the
            compressor will establish 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.


4.7. Using Timer-Based Compression
4.7. タイマーベースの圧縮を使用します

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.


5. List Compression
5.1. CSRC List Items in RTP Dynamic Chain
5.1. RTPダイナミックチェーンにおけるCSRCリストのアイテム

RFC 3095-Section 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、セクション5.7.7.6は、RTPヘッダの静的及び動的部分を定義します。このセクションでは、可変の長さを有する動的鎖、(RFC 3095、セクション5.8.6を参照)に「汎用CSRCリスト」フィールドを示しています。このフィールドは、(RTPのCCフィールドが0に設定されているときに存在しない非圧縮RTPヘッダ内のCSRCリストとは対照的に)リストが空であっても、常にサイズが少なくとも1オクテットです。

5.2. Multiple Occurrences of the CC Field
5.2. CCフィールドの複数オカレンス

The static and the dynamic parts of the RTP header are defined in RFC 3095-Section 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

RTPヘッダの静的及び動的な部分はRFC 3095、セクション5.7.7.6で定義されています。動的部分では、CCフィールドが「汎用CSRCリスト」中に存在するCSRCアイテムの数を示します。別のCCフィールドも「ジェネリックCSRCリスト」(RFC 3095 - セクション内に現れます, 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:、符号化タイプ0は、常に動的チェーンで使用されるからです。 CCフィールドの値は、符号化タイプ0のためのCSRCリスト内XI項目の数を決定し、それ以外は使用されません:両方のCCフィールドは同じ意味を持ちます。したがって、以下が適用されます。



"The first octet in the dynamic part of the RTP header contains a CC field, as defined in Section 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.7.7.6で定義されるように、RTPヘッダの動的部分における最初のオクテットは、CCフィールドを含む第2の発生は、RTPヘッダの動的部分でもある 『汎用CSRCリスト』に表示され符号化タイプ0は、RFC 3095-で定義されたフォーマットに応じて使用されます。

The compressor MUST set both occurrences of the CC field to the same value.


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


5.3. Bit Masks in List Compression
5.3. リスト圧縮でのビットマスク

The insertion and/or removal schemes, described in RFC 3095-Sections -, 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、セクション5.8.6.2に記載の挿入及び/又は除去方式、 -は、参照リスト内に挿入または除去位​​置を示すためにビットマスクを使用します。ビットマスクのサイズは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.


5.4. Headers Compressed with List Compression
5.4. リスト圧縮で圧縮されたヘッダ

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、セクション5.8には、拡張ヘッダチェーンの一部であり得るヘッダはAH [14]、ESP NULL [13]、最小カプセル化(MINE)[15]、GRE [16] [17]、 "含まれる" と述べていますそして、IPv6 [9]の拡張機能。圧縮することができるヘッダのこのリストは正確であるが、記載されている唯一のヘッダタイプが実際に取り扱うことができるので、単語「含む」は、そこにあってはなりません。さらに、最小カプセル化(MINE)ヘッダのために、ヘッダが圧縮されていない、または完全に離れ、圧縮のいずれか送信されるように、それを圧縮する方法の明示的な議論が存在しないことに留意すべきです。

5.5. ESP NULL Header List Compression
5.5. ESP NULLヘッダーリスト圧縮

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 [12]ヘッダーとして扱われない限り、ESPヘッダのトレーラ部分のフィールドのオフセット、圧縮機は、複数のNULL ESP [13]のヘッダを含むパケットを圧縮してはいけませんおよびパケットは、プロファイル0x0003を使用して圧縮されています。

5.6. Translation Tables and Indexes for IP Extension Headers
5.6. IP拡張ヘッダーのための翻訳テーブルとインデックス

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 - セクション5.8.4は、リストインデックスの項目とどのようにテーブルのリストはIP拡張ヘッダのために構築されているのリストを表示するために関連付けられている方法を説明します。同じタイプが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.


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

拡張の内容が変化した場合、ヘッダ異なるインデックスを使用するか、または既存のものを更新するのいずれかに、実装が選択することができます。いくつかのフィールドが変更しても、それらの変更は、解凍器に例えば、「IP拡張の一環として、(明示的または暗黙的に(RTP SNから推測できる拡張ヘッダにおける例えばシーケンス番号)を搬送することができるように、一部の拡張機能は、離れて圧縮することができますヘッダ拡張3(S)」フィールド)。

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.


5.7. Reference List
5.7. 参照リスト

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


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が空リストであるとき、タイプ3のリストを送信することはほとんど意味を持っていながら、タイプ2のリストを送信すると、故障につながります。これらすべての選択肢は、リストの圧縮は、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.




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


5.8. Compression of AH and GRE Sequence Numbers
5.8. AHとGREシーケンス番号の圧縮

RFC 3095-Section and RFC 3095-Section 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、セクション5.8.4.2およびRFC 3095、セクション5.8.4.4は、認証ヘッダ(AH)[14]と総称ルーティングカプセル化(GRE)[16] [17]ヘッダーを圧縮する方法について説明します。これらの両方のセクションでは、特定の状況下で、圧縮されたヘッダにAH / GREシーケンス番号を省略する可能性を提示します。しかし、AH / GREシーケンス番号、ならびに適用するための具体的な圧縮および圧縮解除の手順を省略するための具体的な条件は、明らかに堅牢性を保証し、相互運用可能な実装を容易にするために定義されていません。

Proper rules are provided for the ESP case, i.e.,:


"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"


The same logic applies to the AH/GRE sequence numbers.

同じロジックは、AH / GREシーケンス番号に適用されます。

INCORRECT RFC 3095 TEXT (RFC 3095-Section

INCORRECT RFC 3095 TEXT(RFC 3095 - セクション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."




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


INCORRECT RFC 3095 TEXT (RFC 3095-Section

INCORRECT RFC 3095 TEXT(RFC 3095 - セクション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."




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


6. Updating Properties
6.1. Implicit Updates
6.1. 暗黙のアップデート

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.


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を参照)を除いて、明示的または暗黙的に、全てのヘッダフィールドの基準値を更新します。 Rモードでは、CRCを持つすべてのパケットはパケットを更新している間UOモードでは、すべてのパケットは、パケットを更新しています。

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.


6.2. Updating Properties of UO-1*
6.2. UO-1の更新特性*

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 - セクション5.7.3は、UO-1-IDパケットによって運ば拡張で提供される値は、SN、TS、またはIP-IDフィールドを除いて、コンテキストを更新しないと述べています。しかし、RFC 3095 - セクション5.8.1を正しくためUO-1 RFC 3095-5.7.3中の文と矛盾しているもの、(インデックス、項目)組が受信されるたびに、コンテキスト内の変換テーブルが更新されると述べています-IDパケット「が圧縮CSRCリスト」フィールド内(インデックス、項目)対項目に拡張3を運ぶことができます。この矛盾に加えて、テキストが暗黙的に更新されることもあるSNから推測される他のシーケンス番号、をどうするかを言及していません。 RFC 3095、セクション5.7.3によって述べたようにUO-1 *の更新特性は、このように不完全です。

INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7.3):

INCOMPLETE RFC 3095 TEXT(RFC 3095-5.7.3項):

"Values provided in extensions, except those in other SN, TS, or IP-ID fields, do not update the context."




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


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

解凍装置は(インデックス、項目)ペアはRFC 3095、セクション5.8.1に従って、受信されたとき、その変換テーブルを更新しなければならない、このルールは、UO-1-IDパケットにも適用されます。」

6.3. Context Updating Properties for IR Packets
6.3. IRパケットのためのプロパティの更新状況

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.


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.


6.4. RTP Padding Field (R-P) in Extension 3
6.4. エクステンション3でRTPパディングフィールド(R-P)

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、セクション5.7.5エクステンション3のRTPフラグが設定されている場合、これらは、更新さエクステンション3のRTPヘッダフラグおよびフィールドのプロパティを定義する、すなわち、場合RTP = 1。それ以外の場合は、更新されません。しかし、エクステンション3コンテキストでR-Pビットを更新する方法は不明です。

INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7.5):

INCOMPLETE RFC 3095 TEXT(RFC 3095 - セクション5.7.5):

"R-P: RTP Padding bit, absolute value (presumed zero if absent)."




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

"R-P:RTPパディングビットR-PT = 1の場合、R-Pは、RTPパディングビットの絶対値であり、この値の更新コンテキスト(R-P)R-PT = 0の場合、コンテキスト(R-P)をゼロに更新されます。"

6.5. RTP eXtension bit (X) in dynamic part
6.5. 動的部分のRTP拡張ビット(X)

RFC 3095-Section 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、セクション5.7.7.6は、IR及びIR-DYNパケットのダイナミック鎖のRTP部分のRTPヘッダフラグおよびフィールドのプロパティを定義します。しかし、Xビットがコンテキストで更新されるかは不明です。

INCOMPLETE RFC 3095 TEXT (RFC 3095-Section

INCOMPLETE RFC 3095 TEXT(RFC 3095 - セクション5.7.7.6):

"X: Copy of X bit from RTP header (presumed 0 if RX = 0)"

"X:(RX = 0の場合は0を推定)RTPヘッダからXビットのコピー"



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

"X:RTPヘッダからXビットRX = 1の場合、Xは、RTPヘッダと、この値を更新するコンテキスト(X)からXビットであるRX = 0の場合、コンテキスト(X)がゼロに更新されます。。。"

7. Context management and CID/context Reuse
7.コンテキスト管理とCID /コンテキストリユース
7.1. Persistence of Decompressor Contexts
7.1. デコンプレッサのコンテキストの持続性

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と確立されたコンテキストは、解凍器によって維持されなければならない、またはチャネルであります降ろさまたは再交渉。

7.2. CID/Context Reuse
7.2. 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の値は1つのリンク別のアプリケーション、ならびに圧縮するパケットストリームの数の点で荷重とは大きく異なることができます。 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つのサブセクションに別々に議論されています。

7.2.1. Reusing a CID/Context with the Same Profile
7.2.1. 同じプロファイルとCID /コンテキストの再利用

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、セクション5.6で定義されるようなRFC 3095で定義されたもののようなマルチモードプロファイル、[1]、モード遷移は、デコンプレッサが開始ハンドシェーク手順を使用して行われます。 CID /コンテキストが古いコンテキストと同じプロファイルに基づいて新しいコンテキストのために再利用された場合、現在の動作モードは、新しいコンテキストに古いから継承されるべきです。具体的には、圧縮機は、新たな文脈でも、古いコンテキストの動作モードを使用して動作を継続する必要があります。この理由は、コンプレッサーがCID /コンテキストの再利用が起こっているデコンプレッサに通知するための信頼できる方法がないことです。解凍装置は、このように(セクション6.3を参照)CIDのコンテキストメモリをクリアすることが期待できず、(デコンプレッサが開始ハンドシェーク手順を必要とする)安全なモード切替をトリガーする方法はありません。

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.

CONTEXT_REINITIALIZATION信号(RFC 3095、セクション6.3.1)が全体のコンテキストを再開するために使用されたときにモードの継承のルールも適用されます。

7.2.2. Reusing a CID/Context with a Different Profile
7.2.2. 異なるプロファイルとCID /コンテキストの再利用

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-開始新しいコンテキストおよびプロファイルダウングレードに適用される(例えば、プロファイルは0x0001 - RFC 3095、セクション5.11.1に>プロフィール0×0002のダウングレード)。

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-及びRモードで異なるフォーマットを有しており、これらの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によっての誤った解釈の危険性を最小限に抑えるべきです。

8. Other Protocol Clarifications
8.1. Meaning of NBO
8.1. NBOの意味

In IPv4 dynamic part (RFC 3095-Section, if the 'NBO' bit is set, it means that network byte order is used.

「NBO」ビットが設定されている場合はIPv4動的部分(RFC 3095、セクション5.7.7.4)において、は、ネットワークバイト順が使用されていることを意味します。

8.2. IP-ID
8.2. IP-ID

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、セクション5.7によれば、IP-IDは、IPv4ヘッダの「識別」フィールドの圧縮された値を意味します。 IR動的鎖を有するパケット及びIR-DYNパケットは、元の非圧縮識別フィールド値を送信しながら、圧縮されたパケットは、この圧縮された値(IP-ID)を含みます。 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(s)は(ある)IP-IDの説明によれば、圧縮されたベースヘッダの終わりに、16ビット非圧縮の識別値(複数可)として送信され(参照RFC 3095 - セクション5.7)の始まり。全く圧縮されたIP-IDが存在しない場合、すなわち、であるように、すべてのIP識別情報が送信されたIPv6又は(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オフセットとバイトスワップとして、即ち、表現。これは、IP-IDの16ビットは拡張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ビットは圧縮ヘッダで送信されていない場合、SNは、セクション4.5.5に記載したようにIP-IDは、Offset_mはOffset_refに等しいことを意味し、不変のままのオフセット。これはさらに、言われている5.7項における「デフォルトスロープ(IP-IDオフセット)= 0」(同じ意味で)わずかに異なる方法で表現され、意味、何ビットがIP-IDのために送信されていない場合、そのSNは0にスロープのデフォルトを相殺しました。

8.3. Extension-3 in UOR-2* Packets
8.3. 拡張-3 UOR-2 *パケットに

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.

拡張子(例えば、NBOまたはRND)でIPヘッダの一部のフラグはUOR-2 *パケット内のフィールドの解釈を変更してもよいです。このような場合には、エクステンション3のフラグ変化は、減圧装置はUOR-2 *パケットを再解析する必要がある場合。

8.4. Multiple Occurrences of the M Bit
8.4. Mビットの複数の出現

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.

エクステンション3のRTPヘッダ部は、RFC 3095、セクション5.7.5によって定義されるように、RTPマーカビットのための1ビットのフィールドを含みます。このフィールドは、UO-1-ID以外のすべての圧縮されたベースヘッダフォーマットも存在します。意味、単一の圧縮ヘッダ内のフィールドの2つの存在があってもよいです。このような場合には、2つのMフィールドが同じ値を持つ必要があります。



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


At the decompressor, if the two M field values of such a packet are not identical, the packet MUST be discarded."


8.5. Multiple SN options in one feedback packet
8.5. 1件のフィードバックパケット内の複数のSNオプション

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 allows for 8 additional SN bits to the 12 SN bits of the FEEDBACK-2 format (RFC 3095-Section 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)はFEEDBACK-2形式の12ビットのSN 8追加のSNビット(RFC 3095、セクション5.7.6.1)を可能にします。それは1つのフィードバックパケットで複数のSNオプションを使用しない限り、解凍器は、フィードバックパケットにおけるESPのシーケンス番号のすべての32ビットを返送するために一つのSNフィードバックオプションは、このように十分ではありません。

RFC 3095-Section declares that a FEEDBACK-2 packet can contain a variable number of feedback options, and the options can appear in any order.

RFC 3095 - セクション5.7.6.1は、FEEDBACK-2パケットは、フィードバックオプションの可変数を含むことができ、およびオプションは任意の順序で表示されますことを宣言します。

When processing multiple SN options in one feedback packet, the SN would be given by concatenating the fields.


8.6. Multiple CRC Options in One Feedback Packet
8.6. 一つのフィードバックパケット内の複数のCRCオプション

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.


8.7. Responding to Lost Feedback Links
8.7. ロストフィードバックリンクへの対応

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を使用する必要があります。これは(セクション7.2を参照)流れはUモードで再起動されたときに、U / Oモード及びRモードの両方に共通しているパケットタイプ識別子の圧縮ヘッダの種類を誤って解釈する可能性を回避するのに有用です。

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.


8.8. UOR-2 in Profile 0x0002 (UDP) and Profile 0x0003 (ESP)
8.8. UOR-2プロファイルの0×0002(UDP)およびプロファイル0x0003で(ESP)

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

一つの新しいフォーマットは、プロファイルは0x0001から3つ全ての(UOR-2、UOR-2-ID、UOR-2-TS)のフォーマットを置き換えプロファイル0×0002とプロファイル0x0003にUOR-2のために定義されています。同じUOR-2フォーマットは、このように対応するRND = 1とIPヘッダが存在するか否かとは無関係に使用されます。これはまた、[4] IPプロファイルに適用され、IP / UDP-Liteのプロフィール[5]。

8.9. Sequence Number LSB's in IP Extension Headers
8.9. IP拡張ヘッダー内のシーケンス番号のLSB

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、セクション5.8.5では、フォーマットはIP拡張ヘッダフィールドの圧縮のために定義されています。これらは、圧縮されたシーケンス番号フィールドが含まれ、これらのフィールドは、「LSBシーケンス番号の」が含まれています。これらのシーケンス番号は、RTPシーケンス番号、例えば、として「LSBでエンコードされた」ものではなく、圧縮されていないフィールドのLSBのです。

8.10. Expecting UOR-2 ACKs in O-Mode
8.10. OモードでUOR-2のACKを期待

Usage of UOR-2 ACKs in O-mode, as discussed in RFC 3095-Section, 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.

OモードでUOR-2 ACKの使用は、RFC 3095、セクション5.で説明したように、任意です。デコンプレッサはまた、すべてのUOR-2に対するACKの送信を継続することなく、UOR-2を確認する以外の目的のためにACKを送信することができます。同様に、圧縮機の実装は、楽観的なアプローチ戦略を適応させるためにUOR-2SのACKを無視することができます。

It is thus NOT RECOMMENDED to use the optional ACK mechanism in O-mode, either in compressor or in decompressor implementations.


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, 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のACKに誤った期待を使用すると、大幅に圧縮性能を劣化させます。そのようなクロックの分解能としてフィードバックを送信するために、又はモード遷移を開始するために、例えば、UOR-2パケットを認識するよりも、UOR-2 ACKが他の目的のために解凍装置から送信することができるからです。実装は、セクション5.で説明するオプションの確認応答アルゴリズムを使用しない場合、それが原因上記の問題にコンプレッサー性能が劣化しないことを保証するために、1よりもはるかに大きい値にK_3とn_3パラメータを設定することを確認しなければなりません。

8.11. Context Repairs, TS_STRIDE and TIME_STRIDE
8.11. コンテキスト修理、TS_STRIDEとTIME_STRIDE

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.


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パケットタイプは、しかし、これらのフィールドは、このパケットタイプのためのRTP TSフィールドの復元のために使用されていないエクステンション3と、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.




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


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


9. ROHC Negotiation
9. ROHC交渉

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、セクション5.1.1に記載されているチャネルパラメータを交渉するための手段を提供しなければならないことをRFC 3095、セクション4.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.

各プロファイルは、8つのLSBビットが実際のプロファイルを示す16ビットの値によって識別され、8つのMSBビットは、そのプロファイル(RFC 3095、セクション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.


10. PROFILES Sub-option in ROHC-over-PPP
ROHCオーバーPPPで10 PROFILESサブオプション

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]は、全体の組合は、次に回避するために、2つのIPCPネゴシエーションの各々内で考慮されなければならないように、プロファイルサブオプションのために使用することができませんあいまいなプロファイルセットを取得。 RFC 3241の実装は、従って、同じプロファイル・セットは、IPv4およびIPv6(IPCP / IPV6CP)の両方のために交渉されていることを確認しなければなりません。

11. Constant IP-ID Encoding in IP-only and UPD-Lite Profiles

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のセクション3.3 [4]、IPv4の一定の識別値を符号化するための機構(一定のIP-ID)が定義されています。このメカニズムは、RFC 4019 [5]、ROHC UDP-Liteのプロファイルによって使用されています。

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.


12. Security Considerations

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.


13. Acknowledgments

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、カルステンボルマン、ミカエルDegermark、志剛劉、アビゲイルサーティース、マーク・西、トミーLundemo、アラン・ケニントン、レミPelland、ラヨシュZaccomer、エンドレSzalai、マーク・Kalmanczhelyi、およびアルパドSzakacsに感謝したいと思います。おかげでもワーキンググループラストコール中にドキュメントをレビューし、コミット文書の校閲、カールKnutssonとBiplabサルカール、へ。

14. References
14.1. Normative References
14.1. 引用規格

[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]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.、およびH.鄭、「ロバストヘッダ圧縮(ROHC):フレームワークおよび4つのプロファイル:RTP、UDP、 ESP、および非圧縮」、RFC 3095、2001年7月。

[2] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.

[2]ボルマン、C.、 "PPPオーバーロバストヘッダ圧縮(ROHC)"、RFC 3241、2002年4月。

[3] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.

[3]、STD 51、RFC 1662、1994年7月シンプソン、W.、 "HDLC様のフレーミングにおけるPPPを"。

[4] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A Compression Profile for IP", RFC 3843, June 2004.

[4]ジョンソン、L-E。そして、G.ペルティエ、 "ロバストヘッダ圧縮(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]ペルティエ、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

14.2. Informative References
14.2. 参考文献

[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]ヨンソン、L-E、ペルティエ、G.、およびK. Sandlund、 "ロバストヘッダ圧縮(ROHC):IP / UDP / RTPのためのリンク層補助プロファイル"、RFC 4362、2006年1月。

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

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

[9] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

[9]デアリング、S.とR. Hindenと "インターネットプロトコル、バージョン6(IPv6)の仕様"、RFC 2460、1998年12月。

[10] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.

[10]ポステル、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.、フレデリック、R.、およびV.ヤコブソン、 "RTP:リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。

[12] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.

[12]ケント、S.、 "IPカプセル化セキュリティペイロード(ESP)"、RFC 4303、2005年12月。

[13] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.

[13]グレン、R.とS.ケント、 "NULL暗号化アルゴリズムとIPsecでの使用"、RFC 2410、1998年11月。

[14] Kent, S., "IP Authentication Header", RFC 4302, December 2005.

[14]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。

[15] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.

[15]パーキンス、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]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、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月。

Appendix A. Sample CRC Algorithm


   #!/usr/bin/perl -w
   use strict;
   # ROHC CRC demo - Carsten Bormann 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;
   # 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:

選択ラース・エリックジョンソンSE-831 92 737エステルスンド、スウェーデン電話:+46 70 365 8時58分、午後電子メール

Kristofer Sandlund Ericsson AB Box 920 SE-971 28 Lulea, Sweden Phone: +46 8 404 41 58 EMail:

クリストファーSandlundエリクソンABボックス920 SE-971 28ルーレオ、スウェーデン電話:+46 8 404 41 58 Eメール

Ghyslain Pelletier Ericsson AB Box 920 SE-971 28 Lulea, Sweden Phone: +46 8 404 29 43 EMail:

GhyslainペルティエエリクソンABボックス920 SE-971 28ルーレオ、スウェーデン電話:+46 8 404 29 43 Eメール

Peter Kremer Conformance and Software Test Laboratory Ericsson Hungary H-1300 Bp. 3., P.O. Box 107, HUNGARY Phone: +36 1 437 7033 EMail:

ピーター・クレーメル適合性とソフトウェアテスト研究所エリクソンハンガリーH-1300 Bpと。 3.、私書箱ボックス107、ハンガリー電話:+36 1 437 7033 Eメール

Full Copyright Statement


Copyright (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に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。


この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、(もしあれば)を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

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


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は、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。



Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。