[要約] RFC 3408は、ROHCプロファイルでの双方向信頼性モード（R-mode）におけるゼロバイトのサポートについて説明しています。このRFCの目的は、ROHCプロトコルの拡張リンク層支援において、ゼロバイトの使用を可能にすることです。
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
拡張リンク層アシストロバストヘッダー圧縮（ROHC）プロファイルにおける双方向信頼できるモード（Rモード）のゼロバイトサポート
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.
Copyright（c）The Internet Society（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.
このドキュメントでは、RFC 3242で定義された2つを超えて、ゼロバイトプロファイルとも呼ばれるリンク層アシストロバストヘッダー圧縮（ROHC）プロファイルの追加モードを定義します。Packet Voice Streamをラジオの次のより高い固定パケットサイズに押し込むことから、Octet 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パケットを圧縮するためのゼロバイトソリューションを定義します[RFC3095]。現在の仕様は、[RFC3242]で定義されたプロファイルを拡張して、双方向信頼性（R-）モードのゼロバイトサポートを提供します。この仕様と[RFC3242]を使用すると、すべてのモードでヘッダーフリーパケット形式を使用して、通常の動作中に送信されるROHC RTPパケットの1-OCTETヘッダーの大部分を置き換えることができます。具体的には、Rモードで動作するコンプレッサーは、[RFC3242]がROHC信頼できるパケットタイプゼロ（R-0）パケット[RFC3095]を配信するために必要な場合に、非ヘッダーパケット（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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
- Sn_acked、認められている最新のRTP SNを示しています。モード値= r-Modeの場合にのみ使用されます。
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を送信することがしばしば安全になるように動作する場合、この追加インターフェイスを実装することをお勧めします。ここで、「Unsafe」という言葉は、コンプレッサーがALがNHPを送信できるようにすることを意味しますが、ALはNHPのRTP SNが受信側で正しく減圧されることを保証することはできません。インターフェイスは、セクション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モードの場合、このプロファイルは、R-0パケットのマッピングをNHPパケットに実行することによりROHC RTPを拡張します。R-0は、NHPに置き換えることができるR-Modeの唯一のタイプのパケットであることに注意してください。
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は減圧器AS = SN_REF_D OFFSET_Dによって決定されます。SN_REF_Dは、減圧器が受信した最後の更新パケットのRTP SNであり、NHPと最後の更新の間のシーケンス番号オフセットによって決定されます。パケット。Offset_dを導出する方法は、特定のリンクテクノロジーを介したこのプロファイルの実装に依存し、実装ドキュメントで指定する必要があります。たとえば、最後に成功したコンテキストアップデート以降に受け取った非コンテキストアップデートパケット（NHPを含む）の総数をカウントすることで計算できます。あるいは、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は[RFC3242]のセクション4.1.1で定義されている同じルールに従って、1つの変更でNHPを送信できるかどうかを判断します。つまり、ALがNHPSを送信するために安全でないと判断した場合、ALは対応するRTP SNをSN_BREAKとして記録します。その後、ルールが再び満たされ、sn_acked> sn_breakが再開されるまで、NHPSの送信を再開するまで待ちます。後者の条件は、基本的に、U/OモードのALがNHPを送信することが安全でないと判断した場合、後続のヘッダーを送信する必要があると判断するU/Oモードの楽観的アプローチ契約[RFC3242、セクション4.3]の対応物です。Xパケット、ここで、xは合意された数字です。違いには2つの理由があります。a）Rモードは、U/Oモードのように楽観的なアプローチの原則ではなく、コンテキストを同期するための承認に依存しています。b）R-0パケットは、UO-0パケットが行われている間、減圧器のコンテキストを更新しません。条件SN_ACKED> sn_breakを満たすために、ALはコンプレッサーがコンテキストアップデートパケットを送信するのを受動的に待つことができます（例：6ビットSNラップアラウンドでトリガーされるR-0-CRC）、またはインターフェイスを介してupdate_requestを送信します。ALはコンプレッサー（セクション2.2）に、コンプレッサーにコンテキストの更新パケットを送信するように要求します。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.
注：上記のパッシブ待機は、最悪の場合には長い時間がかかる場合があり、その間にNHPを送信できません。したがって、最悪の場合のパフォーマンスを改善するために、オプションの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が失われる場合がありますが、そのような損失はALがNHPの送信を再開することを遅らせるだけです。したがって、ALがupdate_requestを送信する頻度は実装の問題です。たとえば、ALは、NHPが満たされる条件が満たされるまで、コンプレッサーから受信する各パケットに対して1つの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.
注：R-0パケットにはCRCフィールドが存在しないため、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.
a) CRCの交換、U/Oモード、CRC交換[RFC3242、セクション3.3]とは異なり、R-0パケットはCRCフィールドを運ばないため、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.
b) U/Oモードの定期的なコンテキスト検証、定期的なコンテキスト検証[RFC3242、セクション4.6]は、CRCが置き換えられた後の損傷伝播に対する追加の保護を提供するために推奨されます。Rモードの場合、CRCの交換がないため（上記参照）、この点に関してROHC RTPに変更は必要ありません。特に、R-Modeにはこの機能が自然に組み込まれています。これは、6ビットSNがrapsを包み回すと、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-Modeで動作するコンプレッサーはCビットを0（ゼロ）に設定し、コンプレッサーと分解器で計算コストが原因の場合は7ビットCRCを生成しないはずです。懸念。分解器のコンテキスト検証を実行するためのCCPでのCRCフィールドの使用は、上記のRモード（セクション3および項目Bの最後のメモを参照）では重要ではありません）。
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シーケンスを中断し、したがってNHPの送信を一時的に無効にするためです。
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プロファイル識別子は、このドキュメント（0x0105）で定義されているプロファイルのIANAによって予約されています。ここで、0x0005はLLAに割り当てられたプロファイル識別子です[RFC3242]。
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.
ROHC RTP [RFC3095、セクション7]のセキュリティ上の考慮事項は、1つの追加でこのドキュメントにも適用されます。侵入者がランダムCRC値、CRCを使用してリンクに偽のCCPパケットを注入するサービス拒否攻撃シナリオの場合、CRC小切手は、減圧器側で誤った理由で失敗します。これにより、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-Modeの操作を特定するのに役立ったLLAに関する興味深い議論をしてくれたLars-Erik JonssonとGhyslain Pelletierに感謝したいと思います。著者はまた、Carsten Bormann、Christopher Clanton、Mark Cheng、およびThinh 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] Jonsson、L。およびG. Pelletier、「Robust Header Compression（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] 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。、およびH. Zheng、 "堅牢なヘッダー圧縮（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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
Zhigang Liu Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA
Zhigang Liu Nokia Research Center 6000 Connection Drive Irving、TX 75039 USA
Phone: +1 972 894-5935
Fax: +1 972 894-4589
EMail zhigang.c.liu@nokia.com
Khiem Le Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA
Khiem Le Nokia Research Center 6000 Connection Drive Irving、TX 75039 USA
Phone: +1 972 894-4882
Fax: +1 972 894-4589
EMail: khiem.le@nokia.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。