Network Working Group Z. Liu
Request for Comments: 3408 K. Le
Category: Standards Track Nokia
December 2002
Zero-byte Support for Bidirectional Reliable Mode (R-mode)
in Extended Link-Layer Assisted RObust Header Compression
(ROHC) Profile
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document defines an additional mode of the link-layer assisted RObust Header Compression (ROHC) profile, also known as the zero-byte profile, beyond the two defined in RFC 3242. Zero-byte header compression exists in order to prevent the single-octet ROHC header from pushing a packet voice stream into the next higher fixed packet size for the radio. It is usable in certain widely deployed older air interfaces. This document adds the zero-byte operation for ROHC Bidirectional Reliable mode (R-mode) to the ones specified for Unidirectional (U-mode) and Bidirectional Optimistic (O-mode) modes of header compression in RFC 3242.
この文書は、3242 0バイトのヘッダー圧縮は単一のを防止するために存在するRFCに定義された2つ超え、ゼロバイトのプロファイルとして知られているリンク層支援ロバストヘッダ圧縮（ROHC）プロファイルの追加のモードを定義します無線の次に高い固定パケットサイズにパケット音声ストリームをプッシュからオクテットROHCヘッダ。これは、特定の広く配備古いエアインタフェースで使用可能です。この文書は、RFC 3242でヘッダ圧縮の一方向（Uモード）と双方向楽観（Oモード）モードに指定されたものにROHC双方向信頼できるモード（Rモード）ゼロバイト動作を追加します。
[RFC3242] defines a zero-byte solution for compression of IP/UDP/RTP packets only for Unidirectional (U-) and Bidirectional Optimistic (O-) modes [RFC3095]. The present specification extends the profile defined in [RFC3242] to provide zero-byte support for Bidirectional Reliable (R-) mode. This specification and [RFC3242] allow a header-free packet format to be used in all modes to replace the majority of the 1-octet headers of ROHC RTP packets sent during normal operation. Specifically, the compressor operating in R-mode is allowed to deliver a No-Header Packet (NHP) when [RFC3242] would have required it to deliver a ROHC Reliable Packet Type Zero (R-0) packet [RFC3095].
[RFC3242]は一方向のみ（U-）および双方向楽観（O-）モード[RFC3095]のためのIP / UDP / RTPパケットの圧縮のための0バイトの溶液を画定します。本明細書は、双方向の信頼性（R-）モードの0バイトのサポートを提供するために、[RFC3242]で定義されたプロファイルを拡張します。本明細書および[RFC3242]はヘッダを含まないパケットフォーマットは、通常動作中に送信されるROHC RTPパケットの1オクテットヘッダーの大部分を置き換えるために、すべてのモードで使用することを可能にします。 [RFC3242]はROHC信頼できるパケットタイプゼロ（R-0）パケット[RFC3095]を送達するためにそれを必要とした場合、具体的に、R-モードで動作する圧縮機が無ヘッダパケット（NHP）を送達することができます。
For simplification, this profile is defined in the form of the additions and exceptions to [RFC3242] that are required to extend the RFC 3242 profile with zero-byte support for R-mode. All terminology used in this document is the same as in [RFC3242].
簡略化のために、このプロファイルはRモード用のゼロバイトをサポートしてRFC 3242のプロファイルを拡張するために必要とされる[RFC3242]への追加および例外の形で定義されています。このドキュメントで使用されるすべての用語は、[RFC3242]と同じです。
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 BCP 14, RFC 2119 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
This section describes additions (some are optional) to the assisting layer interface as defined in [RFC3242, section 4.2].
[RFC3242、セクション4.2]で定義されるように、このセクションでは、補助層の界面への追加を（いくつかはオプションである）について説明します。
- Mode, indicating the mode in which the compressor is operating. The AL has slightly different logic depending on the mode value.
- モード、圧縮機が動作しているモードを示します。 ALは、モード値に応じてわずかに異なるロジックを有します。
- SN_ACKed, indicating the latest RTP SN that has been acknowledged. It is used only when Mode value = R-mode.
- 認識されている最新のRTPのSNを示し、SN_ACKed。これは、場合にのみ、モード値= Rモードに使用されます。
Note that these two parameters MUST always be attached to every packet delivered to the AL.
これら2つのパラメータは常にALに配信されるすべてのパケットに添付しなければならないことに注意してください。
To improve the compression efficiency of this profile in some specific cases, e.g., when the AL operates in such a way that it often becomes unsafe to send NHPs, it is RECOMMENDED to implement this additional interface. Here, the word "unsafe" means that the compressor allows the AL to send NHP but the AL cannot guarantee that the RTP SN of the NHP will be correctly decompressed at the receiving side. The interface is used to carry update_request as described in section 3. Note that this interface is not required in the sense that the impossibility of implementing such an interface should not be an obstacle to implement this profile over a specific link.
ALは、それがしばしばNHPSを送信する危険になるような方法で動作する場合、いくつかの特定のケースでは、このプロファイルの圧縮効率を向上させるために、例えば、この追加のインタフェースを実装することが推奨されます。ここでは、「安全でない」という言葉は、コンプレッサがNHPが、ALは、NHPのRTP SNが正しく受信側で解凍されることを保証することはできません送信するためにALを可能にすることを意味します。インターフェースは、このインターフェースは、このようなインタフェースを実装するのが不可能特定のリンク上でこのプロファイルを実装する障害であってはならないという意味で必要とされないこと部3注記に記載されているようにUPDATE_REQUEST運ぶために使用されます。
For the R-mode, this profile extends ROHC RTP by performing a mapping of the R-0 packet to the NHP packet. Note that R-0 is the only type of packets in R-mode that can be replaced with NHP.
Rモードのために、このプロファイルは、NHPパケットにR-0パケットのマッピングを行うことにより、ROHC RTPを拡張します。 R-0は、NHPに置き換えることができるRモードにおけるパケットの唯一のタイプであることに留意されたいです。
On the receiving side, the RTP SN of an NHP is determined by the decompressor as = SN_Ref_D + Offset_D, where SN_Ref_D is the RTP SN of the last update packet received by the decompressor, and Offset_D the sequence number offset between the NHP and the last update packet. How to derive Offset_D depends on the implementation of this profile over a specific link technology and must be specified in the implementation document(s). For example, it can be calculated by counting the total number of non-context-updating packets (including NHPs) and packet loss indications received since the last successful context update. Alternatively, it can be derived using the link timing in the case where the linear mapping between RTP SN and link timing is maintained.
受信側では、NHPのRTP SNはSN_Ref_Dは減圧装置によって受信された最後のアップデートパケットのRTP SNである= SN_Ref_D + Offset_Dとして解凍装置によって決定され、NHPと最後の間のオフセットのシーケンス番号をOffset_Dれますパケットを更新します。 Offset_Dを導出する方法の特定のリンク技術の上にこのプロファイルの実装に依存し、実装の文書で指定する必要があります。例えば、（NHPSを含む）は、非コンテキスト更新パケットおよび最後に成功したコンテキストの更新以降に受信パケット損失指標の総数をカウントすることによって算出することができます。あるいは、RTP SNとリンクタイミングとの間の線形マッピングが維持されている場合には、リンクタイミングを用いて導出することができます。
On the transmitting side, the AL follows the same rule defined in section 4.1.1 of [RFC3242] to determine whether it can send NHP or not, with one modification. That is, when the AL determines that it has become unsafe (see section 2.2) to send NHPs, the AL records the corresponding RTP SN as SN_break. Then it waits until the rule is satisfied again and SN_ACKed > SN_break before it resumes sending NHPs. The latter condition is essentially the counterpart of optimistic approach agreement [RFC3242, section 4.3] of U/O-mode which states that when the AL in U/O-mode determines it is unsafe to send NHP, it must send headers in the subsequent X packets, where X is some agreed number. There are two reasons for the difference: a) R-mode relies on acknowledgements to synchronize contexts, instead of optimistic approach principle as in U/O-mode; and b) R-0 packets do not update decompressor context while UO-0 packets do. To meet the condition SN_ACKed > SN_break, the AL can either wait passively for the compressor to send a context update packet (e.g., R-0-CRC triggered by 6-bit SN wrap-around), or send an update_request via the interface from AL to the compressor (section 2.2) to request the compressor to send a context updating packet. The update_request carries the last SN_break. Upon receiving an update_request, the compressor SHOULD use a context updating packet (e.g. R-0-CRC) when sending the next packet. Context updating packets are handled as in [RFC3095].
送信側では、ALは、一の変形で、NHPを送信できるかどうかを決定するために[RFC3242]のセクション4.1.1で定義された同じルールに従います。すなわち、NHPSを送信する（セクション2.2を参照）ALはそれが危険になったと判断した場合、である、ALはSN_breakとして、対応するRTP SNを記録します。それはNHPSの送信を再開する前にルールが再び満足してSN_ACKed> SN_breakになるまで待機します。後者の条件は、本質的に、AL Uに/ Oモードは、NHPを送信するために安全でない判定した場合、それは後続のヘッダーを送信する必要があることをU / Oモードの楽観アプローチの契約の相手[RFC3242、セクション4.3]でありますXは、いくつかの合意の数であるXパケット、。差のための2つの理由がある：a）RモードはU / Oモードのように代わりに楽観アプローチの原理、コンテキストを同期させるために肯定応答に依存しています。 UO-0パケットを行いながらB）R-0パケットは、解凍器のコンテキストを更新しません。 >条件はSN_ACKed SN_breakを満たすため、ALがコンテキスト更新パケットを送信するために圧縮機の受動的に待機するか（例えば、R-0-CRCは、6ビットのSNのラップアラウンドによってトリガ）、またはからインタフェースを介しUPDATE_REQUESTを送ります圧縮機（セクション2.2）にALは、コンテキスト更新パケットを送信するようにコンプレッサを要求します。 UPDATE_REQUESTは最後SN_breakを運びます。次のパケットを送信するときUPDATE_REQUESTを受信すると、圧縮機は、コンテキスト更新パケット（例えば、R-0-CRC）を使用してください。コンテキスト更新パケットは、[RFC3095]のように扱われます。
Note: the passive waiting as described above might take a long time in the worst case, during which NHPs cannot be sent. Therefore, sending update_request via the optional AL to compressor interface is RECOMMENDED to improve the worst case performance.
注意：上記のように受動的待機は、NHPSを送信することはできません、その間最悪の場合には長い時間が、かかる場合があります。したがって、圧縮機インタフェースに任意AL介しUPDATE_REQUEST送信最悪の場合の性能を向上させることが推奨されます。
Note: the update_request may be lost if the AL and compressor are at different locations and the channel between them is unreliable, but such a loss only delays the AL from resuming sending NHP. Therefore, how frequent the AL sends update_request is an implementation issue. For example, the AL may send one update_request for each packet it receives from the compressor until the conditions to send NHP are met.
注：Alおよびコンプレッサは異なる場所にある場合UPDATE_REQUESTが失われる可能性があり、それらの間のチャネルが信頼できないが、このような損失は、送信NHPを再開からALを遅延させます。そのため、ALが送信する方法を頻繁UPDATE_REQUESTは実装の問題です。例えば、ALはNHPを送信するための条件が満たされるまで、圧縮機から受信した各パケットのための一つUPDATE_REQUESTを送信してもよいです。
Note: as no CRC field is present in R-0 packets, only the function related to RTP SN and packet type identifier needs to be replaced. In addition, NHP packets and packet loss indications in R-mode do not update either the compressor or the decompressor context (as opposed to U/O-mode). Consequently, the secure reference principle [RFC3095, section 5.5] is not affected in any way and there is no loss of robustness in this profile compared to ROHC RTP.
注：CRCフィールドは、R-0パケットに存在しないように、RTP SNおよびパケットタイプ識別子に関連する機能のみを交換する必要があります。また、RモードでNHPパケットおよびパケット損失指標は、圧縮または解凍器のコンテキスト（U / Oモードとは対照的に）のいずれかを更新しません。したがって、セキュアリファレンス原理[RFC3095、セクション5.5]は、任意の方法で影響を受けず、ROHC RTPと比較して、このプロファイルに堅牢の損失はありません。
This section clarifies some differences between R-mode and U/O-mode in this profile.
このセクションでは、このプロファイルでRモードおよびU / Oモードの間にいくつかの違いを明確。
a) CRC replacement Unlike U/O-mode, CRC replacement [RFC3242, section 3.3] is not an issue for R-mode since R-0 packets do not carry CRC field.
R-0パケットはCRCフィールドを運ばないのでA）U / Oモードとは異なりCRC置換は、CRC置換[RFC3242、セクション3.3] R-モードの問題ではありません。
b) Periodic context verification For U/O-mode, periodic context verification [RFC3242, section 4.6] is RECOMMENDED to provide additional protection against damage propagation after CRC is replaced. For R-mode, since there is no CRC replacement (see above), no change to ROHC RTP is needed in this regard. In particular, R-mode has this feature naturally built-in, since the sending of R-0-CRC when 6-bit SN wraps around implicitly provides periodic context verification for R-mode.
U / Oモード、周期的なコンテキスト検証[RFC3242、セクション4.6]についてB）定期コンテキスト検証がCRCが交換された後にダメージ伝播に対する追加の保護を提供することをお勧めします。全くCRC置換（上記参照）が存在しないので、Rモードのために、ROHC RTPへの変更は、この点で必要とされません。 6ビットのSNが暗黙Rモードのための周期的なコンテキスト検証を提供するラップアラウンドするときR-0-CRCを送信するので、特に、R-modeは、この機能は天然に組み込まれています。
c) CV-REQUEST option For the same reasons as above, the decompressor operating in R-mode SHOULD NOT send CV-REQUEST [RFC3242, section 4.5] to compressor. This is to avoid unnecessary overhead on the feedback channel.
上記と同じ理由からC）CV-REQUESTオプション、Rモードで動作するデコンプレッサは、コンプレッサにCV-REQUEST [RFC3242、セクション4.5]を送るべきではありません。これは、フィードバックチャネル上で不要なオーバーヘッドを回避することです。
d) Context Check Packet (CCP) When CCP [RFC3242, section 4.1.3] is used, compressor operating in R-mode SHOULD set C-bit to 0 (zero) and not generate 7-bit CRC if computation cost at compressor and decompressor causes concern. The use of the CRC field in CCP to perform decompressor context verification is not critical in R-mode (see last note of section 3 and item b) above).
D）コンテキストパケット（CCP）CCP [RFC3242、セクション4.1.3]を用いた場合、R-モードで動作する圧縮機がゼロ（0 Cビットを設定）としない計算コスト圧縮機であれば、7ビットのCRCを生成し、SHOULDをチェックします。デコンプレッサは、懸念の原因となります。伸張器コンテキストの検証を実行するためCCPにおけるCRCフィールドの使用は、（セクション3とアイテムBの最後の注を参照）、上記）Rモードで重要ではありません。
e) Handling of Acknowledgements (ACKs) Special care in the realization of ACKs should be taken for R-mode implementations. It is RECOMMENDED to avoid the use of interspersed feedback packets [RFC3095, section 5.2.1] to carry ACK information. The reason is that interspersed feedback packets will interrupt the RTP SN sequencing and thus temporarily disable the sending of NHPs.
E）ACKの実現に謝辞（ACKの）特別な注意の取り扱いは、R-モードの実装のために取られるべきです。 ACK情報を運ぶために散在フィードバックパケット[RFC3095、セクション5.2.1]の使用を避けることが推奨されます。その理由は、散在フィードバックパケットがRTP SNシーケンスを中断し、これを一時的NHPSの送信を無効にするということです。
A ROHC profile identifier has been reserved by the IANA for the profile defined in this document (0x0105), where 0x0005 is the profile identifier assigned for LLA [RFC3242].
ROHCプロファイル識別子は0x0005がLLA [RFC3242]に割り当てられたプロファイル識別子であり、この文書（0x0105）で定義されたプロファイルのためにIANAによって予約されています。
The security considerations of ROHC RTP [RFC3095, section 7] apply also to this document with one addition: in the case of a denial-of-service attack scenario where an intruder injects bogus CCP packets onto the link using random CRC values, the CRC check will fail for incorrect reasons at the decompressor side. This would obviously greatly reduce the advantages of ROHC and any extra efficiency provided by this profile due to unnecessary context invalidation, feedback messages and refresh packets. However, the same remarks related to the presence of such an intruder apply.
侵入者がランダムなCRC値を使用して、リンク上に偽のCCPパケットを注入するサービス拒否攻撃のシナリオの場合には、CRC：ROHC RTP [RFC3095、セクション7]のセキュリティ問題は、一加えて、この文書にも適用さチェックは、デコンプレッサ側の間違った理由のために失敗します。これは明らかに大幅にROHCの利点と不必要なコンテキストの無効化、フィードバックメッセージとリフレッシュパケットにこのプロファイルが提供する余分な効率を減少させるであろう。しかし、そのような侵入者の存在に関連した同じ発言が適用されます。
The authors would like to thank Lars-Erik Jonsson and Ghyslain Pelletier for intriguing discussions on LLA that helped to nail down the R-mode operation. The authors also appreciate valuable input from Carsten Bormann, Christopher Clanton, Mark Cheng, and Thinh Nguyenphu.
著者は、R-モード動作を見極めるために役立っLLA上の魅力的な議論のためのラース・エリックジョンソンとGhyslainペルティエに感謝したいと思います。著者らはまた、カルステンボルマン、クリストファー・クラントン、マーク・チェン、そしてティンNguyenphuからの貴重な意見を感謝しています。
[RFC3242] Jonsson, L. and G. Pelletier, "RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242, April 2002.
[RFC3242]ヨンソン、L.とG.ペルティエ、 "ロバストヘッダ圧縮（ROHC）：IP / UDP / RTPのためのリンク層補助プロファイル"、RFC 3242、2002年4月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L., 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.
[RFC3095]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、L.、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.とH.鄭、「ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTP、UDP、ESP 「、および圧縮されていない、RFC 3095、2001年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
Zhigang Liu Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA
志剛劉ノキア・リサーチセンター6000接続のドライブアーヴィング、TX 75039 USA
Phone: +1 972 894-5935 Fax: +1 972 894-4589 EMail zhigang.c.liu@nokia.com
電話：+1 972 894-5935ファックス：+1 972 894-4589 Eメールzhigang.c.liu@nokia.com
Khiem Le Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA
Khiemルノキア・リサーチセンター6000接続のドライブアーヴィング、TX 75039 USA
Phone: +1 972 894-4882 Fax: +1 972 894-4589 EMail: khiem.le@nokia.com
電話：+1 972 894-4882ファックス：+1 972 894-4589 Eメール：khiem.le@nokia.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。