Network Working Group G. Pelletier
Request for Comments: 4164 Ericsson
Category: Standards Track August 2005
RObust Header Compression (ROHC):
Context Replication for ROHC Profiles
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 (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document defines context replication, a complement to the context initialization procedure found in Robust Header Compression (ROHC), as specified in RFC 3095. Profiles defining support for context replication may use the mechanism described herein to establish a new context based on another already existing context. Context replication is introduced to reduce the overhead of the context establishment procedure. It may be especially useful for the compression of multiple short-lived flows that may be occurring simultaneously or near-simultaneously, such as short-lived TCP flows.
RFC 3095.で指定されるように、この文書では、コンテキストの複製、ロバストヘッダ圧縮（ROHC）に見出されるコンテキスト初期化手順を補完を定義する既存の別に基づいて新たなコンテキストを確立するために、本明細書に説明されたメカニズムを使用することができるコンテキストの複製のサポートを定義するプロファイル状況。コンテキストの複製は、コンテキスト確立手順のオーバーヘッドを削減するために導入されます。このような短命のTCPフローとして同時またはほぼ同時に発生することができる複数の短命フローの圧縮のために特に有用である可能性があります。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Context Replication for ROHC Profiles ...........................5
3.1. Robustness Considerations ..................................5
3.2. Replication of Control Fields ..............................5
3.3. Compressor States and Logic ................................6
3.3.1. Context Replication (CR) State ......................6
3.3.2. State Machine with Context Replication ..............7
3.3.3. State Transition Logic ..............................7
3.3.3.1. Selection of Base Context, Upward
Transition .................................8
3.3.3.2. Optimistic Approach, Upward Transition .....9
3.3.3.3. Optional Acknowledgements (ACKs),
Upward Transition ..........................9
3.3.3.4. Negative ACKs (NACKs), Downward
Transition .................................9
3.4. Decompressor Logic ........................................10
3.4.1. Replication and Context Initialization .............10
3.4.2. Reconstruction and Verification ....................10
3.4.3. Actions upon Failure ...............................11
3.4.4. Feedback Logic .....................................11
3.5. Packet Formats ............................................11
3.5.1. CRCs in the IR-CR Packet ...........................12
3.5.1.1. 7-bit CRC .................................13
3.5.1.2. 8-bit CRC .................................13
3.5.2. General Format of the IR-CR Packet .................13
3.5.3. Properties of the Base Context Identifier (BCID) ...15
4. Security Considerations ........................................15
5. Acknowledgements ...............................................15
6. References .....................................................16
6.1. Normative References ......................................16
6.2. Informative References ....................................16
Appendix A: General Format of the IR-CR Packet (Informative).......17
A.1. General Structure (Informative) ..........................17
A.2. Profile-Specific Replication Information (Informative) ...17
Appendix B: Inter-Profile Context Replication (Informative)........18
B.1. Defining Support for Inter-Profile Context Replication ...18
B.2. Compatibility between Different Profiles (Informative) ...19
There is often some redundancy between header fields of different flows that pass through the same compressor-decompressor pair. This means that some of the information needed to initialize the context for decompressing the headers of a new flow may already be present at the decompressor. It may be desirable to reuse this information and remove some of the overhead normally required for the initialization of a new header compression context at both the compressor and decompressor.
同じ圧縮伸長対を通過する異なるフローのヘッダーフィールドとの間のいくらかの冗長性があることが多いです。これは、新しいフローのヘッダを解凍するためにコンテキストを初期化するために必要な情報の一部が既に解凍器で存在することができることを意味しています。この情報を再利用し、通常はコンプレッサーと減圧の両方で新しいヘッダ圧縮コンテキストの初期化に必要なオーバーヘッドの一部を除去することが望ましい場合があります。
Reducing the overhead of the context establishment procedure is particularly useful when multiple short-lived connections (or flows) occur simultaneously, or near-simultaneously, between the same compressor-decompressor pair. Because each new packet stream requires most of the header information to be sent during the initialization phase before smaller compressed headers can be used, a multitude of short-lived connections may significantly reduce the overall gain from header compression.
同じ圧縮伸長ペア間、近同時にコンテキスト確立手順のオーバーヘッドを低減させると同時に発生した場合、複数の短命接続（又はフロー）に特に有用である、または。各新たなパケット・ストリームがより小さな圧縮ヘッダを使用することができる前に、初期化段階中に送信されるヘッダ情報の大部分を必要とするので、短命の接続の多くが大幅ヘッダ圧縮の全体的な利得を減少させることができます。
Context replication allows some header fields, such as the IP source and/or destination addresses (16 octets each for IPv6), to be omitted within the special Initiation and Refresh (IR) packet type specifically defined for replication. It also allows other fields, such as source and/or destination ports, to be either omitted or sent in a compressed form from the very first packet of the header compressed flow.
コンテキストの複製は、具体的には、複製のために定義された特別な開始および更新（IR）パケットタイプ内で省略することが、このようなIPソースおよび/または宛先アドレス（IPv6の16オクテットずつ）のように、いくつかのヘッダフィールドを可能にします。それはまた、省略またはヘッダ圧縮フローの最初のパケットから圧縮形式で送信されるいずれかのそのようなソースおよび/または宛先ポートなどの他のフィールドを、可能にします。
Context replication is herein defined as a general ROHC mechanism. The benefits of context replication are not limited to any particular protocol and its support may be defined for any ROHC profile.
コンテキストの複製は、本明細書で一般的なROHC機構として定義されます。コンテキストの複製の利点は、任意の特定のプロトコルに限定されるものではなく、そのサポートは、任意のROHCプロファイルのために定義することができます。
In particular, context replication is applicable to TCP compression because many TCP transfers are short-lived; a behavior analysis of TCP/IP header fields among multiple short-lived connections may be found in [5]. In addition, [4] introduces considerations and requirements for the ROHC-TCP profile [3] to efficiently compress such short-lived TCP transfers.
多くのTCP転送が短命であるため、特に、文脈模写はTCP圧縮に適用されます。複数短命コネクション間のTCP / IPヘッダフィールドの挙動解析[5]に見出すことができます。また、[4] ROHC-TCPプロファイルの考慮事項および要件を紹介[3]効率的にこのような短命のTCP転送を圧縮します。
For profiles supporting this mechanism, the compressor performs context replication by reusing or creating a copy of an existing context, i.e., a base context, to create the replicated context. The replicated context is then updated to match the header fields of the new flow. The compressor then sends to the decompressor a packet that contains a reference to the selected base context, along with some data for the fields that need to be updated when creating the replicated context. Finally, the decompressor creates the replicated context based on the reference to the base context along with the uncompressed and compressed data from the received packet.
このメカニズムをサポートするプロファイルの場合、圧縮機は、再使用または複製コンテキストを作成するために、既存のコンテキスト、すなわち、ベースコンテキストのコピーを作成することによって、コンテキストの複製を行います。複製されたコンテキストは、新しいフローのヘッダーフィールドと一致するように更新されます。圧縮機は、次に、減圧装置に複製コンテキストを作成するときに更新する必要があるフィールドのためのいくつかのデータと共に、選択されたベースコンテキストへの参照を含むパケットを送信します。最後に、減圧装置は、受信したパケットから非圧縮及び圧縮されたデータと共に基地コンテキストへの参照に基づいて、複製コンテキストを作成します。
This document specifies the context replication procedure for ROHC profiles. It defines the general compressor and decompressor logic used during context replication, as well as the general format of the special IR packet required for this procedure. Profiles defining support for context replication must further specify the specific format(s) of this packet.
この文書では、ROHCプロファイルの文脈模写手順を指定します。これは、コンテキストの複製中に使用される一般的な圧縮装置と解凍ロジック、ならびにこの手順のために必要な特別なIRパケットの一般的なフォーマットを定義します。文脈模写のサポートを定義するプロファイルはさらにこのパケットの特定の形式（複数可）を指定する必要があります。
The fundamentals of the ROHC framework may be found in [2]. It is assumed throughout this document that these are understood.
ROHCフレームワークの基本[2]に見出すことができます。それは、これらが理解されている本書で想定しています。
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 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。
This document reuses some of the terminology found in [2]. In addition, this document defines the following terms:
この文書では、[2]で見つかった用語の一部を再利用します。また、このドキュメントでは、次の用語を定義しています。
Base context
ベースコンテキスト
A base context is a context that has been validated by both the compressor and the decompressor. The compressor can use a base context as the reference when building a new context using replication.
ベースコンテキストは、圧縮器と解凍器の両方によって検証されたコンテキストです。レプリケーションを使用して新しいコンテキストを構築するとき、圧縮機は、基準としてのベースコンテキストを使用することができます。
Base CID (BCID)
ベースCID（BCID）
The Base Context Identifier is the CID used to identify the base context, from which information needed for context replication can be extracted.
ベースコンテキスト識別子CIDは、コンテキスト複製に必要な情報を抽出することができ、そこからベースコンテキストを識別するために使用されます。
Context replication
コンテキストの複製
Context replication is the mechanism that initializes a new context based on another already existing context (a base context).
コンテキストの複製は、他の既存のコンテキストに基づいて新たなコンテキスト（コンテキストベース）を初期化する機構です。
For profiles defining its support, context replication may be used as an alternative to the context initialization procedure found in [2]. Note that for such profiles, only the decompressor is mandated to support context replication; the use of the IR-CR packet is optional for the compressor.
そのサポートを定義プロファイルの場合、コンテキスト複製[2]に見られるコンテキスト初期化手順の代替として使用することができます。そのようなプロファイルのために、唯一のデコンプレッサは、コンテキストの複製をサポートするために義務付けられていることに注意してください。 IR-CRパケットの使用は、圧縮機用オプションです。
This section describes the compressor and decompressor logic as well as the general format of the IR packet used with context replication.
このセクションでは、圧縮装置と解凍ロジック、ならびにコンテキスト複製とともに使用するIRパケットの一般的なフォーマットを記述する。
Context replication deviates from the initialization procedure defined in [2] in that it is able to achieve a certain level of compression from the first packet used to initialize the context for a new flow. Therefore, it is of particular importance that the context replication procedure be robust. This requires that a base context suitable for replication be used, that the integrity of the initialization packet be guaranteed, and finally that the outcome of the replication process be verified.
新たなフローのコンテキストを初期化するために使用される最初のパケットから圧縮の一定のレベルを達成することができるという点でコンテキスト複製が[2]で定義された初期化手順から逸脱します。したがって、それは文脈模写手順は堅牢で特に重要です。これは、初期化パケットの完全性が保証されていること、そして最終的に複製プロセスの結果を検証することを、複製のための適切な塩基のコンテキストが使用されている必要があります。
The primary mechanisms used to achieve robustness of the context replication procedure are the selection of the base context (based on prior feedback from the decompressor) and the use of checksums. Specifically, the compressor must obtain enough confidence that the base context selected for replication is valid and available at the decompressor before initiating the replication procedure. Thus, the most reliable way to select the base context is to choose a context for which at least the static part to be replicated has previously been acknowledged by the decompressor.
コンテキスト複製手順の頑健性を達成するために使用される主なメカニズムは、（減圧装置から前のフィードバックに基づいて）ベースコンテキスト及びチェックサムの使用の選択です。具体的には、圧縮機は、複製のために選択されたベースコンテキストが複製手順を開始する前に、デコンプレッサで有効かつ利用可能であることを十分に確信を得なければなりません。これにより、ベース・コンテキストを選択するための最も信頼できる方法は、複製されるべき少なくとも静的部分は、以前に減圧装置によって承認されたコンテキストを選択することです。
In addition, the presence of a CRC covering the information that initializes the context ensures the integrity of the IR header used for replication. Finally, an additional CRC calculated over the original uncompressed header allows the decompressor to validate the reconstructed header and the outcome of the replication process.
また、コンテキストを初期化情報を覆うCRCの存在は、複製のために使用されるIRヘッダの完全性を保証します。最後に、元の非圧縮ヘッダ上で計算追加のCRCは、減圧装置が再構成されたヘッダおよび複製プロセスの結果を検証することを可能にします。
Control fields are fields that are either transmitted from a ROHC compressor to a ROHC decompressor or inferred based on the behavior of other fields, but are not part of the uncompressed header itself.
制御フィールドのいずれかROHCデコンプレッサにROHC圧縮器から送信された又は他のフィールドの動作に基づいて推測されるフィールドであるが、非圧縮ヘッダ自体の一部ではありません。
They can be used to control compression and decompression behavior, in particular, the set of packet formats to be used. Control fields are profile-specific. Examples of such fields include the NBO and RND flags [2], which indicate whether the IP-ID field is in Network
それらは、特に、パケットフォーマットのセットを使用する、圧縮および圧縮解除の動作を制御するために使用することができます。制御フィールドは、プロファイル固有です。そのようなフィールドの例はIP-IDフィールドは、ネットワーク内にあるかどうかを示すNBOとRNDフラグ[2]を含みます
Byte Order and the type of behavior of the field, respectively. Another example is the parameter indicating the mode of operation [2].
バイト順とそれぞれのフィールドの行動の種類、。別の実施例[2]動作モードを示すパラメータです。
The IR-CR differs from the IR packet [2] in that its purpose is to entirely specify what part of the base context is replicated, and to convey the complementary information needed to create a new context. Because of this, a profile supporting the use of the IR-CR packet SHOULD define for each control field if the value of the field is replicated from the base context to the new context, or if its value is reinitialized.
IR-CR [2]は、その目的が完全に複製され、新しいコンテキストを作成するために必要な補足情報を伝達するために、ベースコンテキストのどの部分を指定することでIRパケットは異なります。このため、IR-CRパケットの使用を支持するプロファイルは、フィールドの値は新しいコンテキストにベースコンテキストから複製された場合、各制御フィールドに定義すべきである、またはその値が再初期化されている場合。
In addition, a compressor MUST NOT initiate context replication while a control field that is not reinitialized by replication is being updated, e.g., during the handshake for a mode transition [2].
レプリケーションによって再初期化されていない制御フィールドが更新されている間に加えて、圧縮機がモード遷移のためのハンドシェイク中に、例えば、コンテキストの複製を開始してはいけません[2]。
Compression with ROHC normally starts in the IR state, where IR packets must be sent to initialize a new context at the decompressor. IR packets include all static and non-static fields of the original header in uncompressed form plus some additional information. The compressor stays in the IR state until it obtains confidence that the decompressor has received the information.
ROHCでの圧縮は、通常、IRパケットがデコンプレッサで新しいコンテキストを初期化するために送られなければならないIR状態で起動します。 IRパケットは、非圧縮形式で元のヘッダーに加え、いくつかの付加的な情報のすべての静的および非静的フィールドを含みます。それはデコンプレッサが情報を受信しているという確信を得るまでコンプレッサーがIR状態に留まります。
Context replication provides an optional mechanism to complement the ROHC initialization procedure. It defines a packet type, the IR packet for Context Replication (IR-CR), which can be used to initialize a new context. Consequently, the Context Replication (CR) state is introduced to the compressor state machine to encompass the additional logic required for the use of the IR-CR packet.
文脈模写はROHC初期化手順を補完するために、オプションのメカニズムを提供します。これは、パケットタイプ、新しいコンテキストを初期化するために使用することができるコンテキストレプリケーション（IR-CR）のIRパケットを定義します。したがって、文脈模写（CR）状態がIR-CRパケットの使用のために必要な追加のロジックを包含するように圧縮状態マシンに導入されます。
For profiles defining support for context replication, the compressor may thus transit directly from the IR state to the CR state if an already existing context can be selected as a base context for replication. This effectively replaces any IR/IR-DYN packets sent during the context establishment procedure with an IR-CR packet.
コンテキスト複製のサポートを定義するプロファイルの場合、圧縮機は、既存のコンテキストは、複製のためのベースコンテキストとしてCRの状態にIR状態から直接従ってトランジット選択することができることがあります。これは、効果的にIR-CRパケットでコンテキスト確立手順中に送信されたIR / IR-DYNパケットを置き換えます。
The purpose of the CR state is to initialize a new context by reusing an already existing context. In this state, the compressor sends a combination of uncompressed and compressed information, along with a reference to a base context plus some additional information. Therefore, header information pertaining to fields that are being replicated is not sent.
CR状態の目的は、既存のコンテキストを再利用して新たなコンテキストを初期化することです。この状態で、圧縮機は、ベースコンテキストに加えて、いくつかの追加情報を参照するとともに、非圧縮及び圧縮された情報の組み合わせを送信します。したがって、複製されたフィールドに関連するヘッダ情報が送信されません。
The compressor stays in the CR state until it is confident that the decompressor has received the replication information correctly.
解凍器が正しくレプリケーション情報を受信したことを確信しているまで、コンプレッサーは、CRの状態のままです。
The compressor always starts in the lower compression state (IR), and transits to the context replication state (CR) under the constraint that the compressor can select a base context that is suitable for the flow being compressed (see also Section 3.3.3.1).
圧縮機は常に（セクション3.3.3.1を参照）低い圧縮状態（IR）で開始し、圧縮機が圧縮されるフローに適しているベースコンテキストを選択することができるという制約下コンテキスト複製状態（CR）に遷移。
The transition from the CR state to a higher compression state (e.g., the CO state for [3]) is based on the optimistic approach principle or feedback received from the decompressor.
（[3]のために、例えば、CO状態）CR状態からより高い圧縮状態への遷移は、解凍器から受信した楽観アプローチの原理、またはフィードバックに基づいています。
The figure below shows the additional state for the compressor. The details of the state transitions and compression logic are given in sub-sections following the figure.
以下の図は、圧縮機のための追加の状態を示しています。状態遷移と圧縮ロジックの詳細は、図以下のサブセクションに記載されています。
BCID selection Optimistic approach / ACK
+----->----->------+ +----->----->----->-----+
| | | |
| v | v
+---------+ +---------+ +-------------+
| IR | | CR | | Higher |
| state | | state | | order state |
+---------+ +---------+ +-------------+
^ |
| NACK / STATIC-NACK |
+---<-----<-----<----+
Note that context replication is a complement to the normal initialization procedure for ROHC profiles that support it. Therefore, the compressor transition to the CR state is an optional addition to the state machine, and does not affect already existing transitions between the IR state and higher order state(s).
そのコンテキストの複製がそれをサポートするROHCプロファイルの通常の初期化手順を補完することに注意してください。したがって、CRの状態に圧縮遷移は、状態マシンに任意に添加され、及びIR状態と高次状態（S）との間の既存の遷移に影響を及ぼしません。
Decisions about transition to and from the CR state are taken by the compressor on the basis of:
およびCRの状態からの遷移についての決定は、に基づいて圧縮機によって取り込まれます。
- availability of a base context - positive feedback from the decompressor (Acknowledgements -- ACKs) - negative feedback from the decompressor (Negative ACKs -- NACKs) - confidence level regarding error-free decompression of a packet
- ベースコンテキストの可用性 - デコンプレッサ（ - のACK謝辞） - から正帰還解凍器からの負のフィードバック（負のACK - のNACK） - パケットのエラーのない伸張に関する信頼レベル
Context replication is designed to operate over links where a feedback channel is available. This is necessary to ensure that the information used to create a new context is synchronized between the compressor and the decompressor. In addition, context replication may also make use of feedback from decompressor to compressor for transition back to the IR state and for OPTIONAL improved forward transition towards a state with a higher compression ratio.
コンテキストの複製は、フィードバック・チャネルが利用可能であるリンク上で動作するように設計されています。これは、新しいコンテキストを作成するために使用される情報は、コンプレッサとデコンプレッサとの間で同期されることを保証する必要があります。また、コンテキストの複製も、バックIR状態に遷移するための圧縮機に解凍器からのフィードバックを利用することができるとOPTIONALのためのより高い圧縮率の状態への移行を前方に改善しました。
The format that must be used by all profiles for the feedback field within the general ROHC format is specified in Section 5.2.2 of [2]; the feedback information is structured using two possible formats: FEEDBACK-1 and FEEDBACK-2. In particular, FEEDBACK-2 can carry one of three possible types of feedback information: ACK, NACK, or STATIC-NACK.
一般的なROHCフォーマット内フィードバックフィールドのすべてのプロファイルで使用されなければならない形式は、[2]のセクション5.2.2で指定されています。 FEEDBACK-1およびFEEDBACK-2：フィードバック情報は、二つの可能なフォーマットを用いて構成されています。 ACK、NACK、またはSTATIC-NACK：特に、FEEDBACK-2は、フィードバック情報の三つの可能なタイプのいずれかを運ぶことができます。
The compressor may initiate a transition from the IR state to the CR state when a suitable base context can be identified. To perform this transition, the compressor selects a context that has previously been acknowledged by the decompressor as the base context. The selected context MUST have been acknowledged by the decompressor using the CRC option (see also [2], Section 5.7.6.3) in the feedback message. The static part of the base context to be replicated MUST have been acknowledged by the decompressor and the base context MUST be valid at replication time.
適切な塩基のコンテキストを識別することができる場合、圧縮機は、CRの状態にIR状態からの遷移を開始することができます。この移行を実行するために、圧縮機は、以前にベースコンテキストとして減圧装置によって承認されたコンテキストを選択します。選択されたコンテキストは、フィードバックメッセージに（セクション5.7.6.3、[2]も参照）CRCオプションを使用して減圧装置によって承認されていなければなりません。レプリケートするベースコンテキストの静的な部分は、解凍器によって承認されていなければならないとベースコンテキストは、レプリケーション時に有効である必要があります。
This also implies that a compressor is not allowed to use the context replication mechanism if a feedback channel is not present. However, note that the presence of the feedback channel cannot provide the guarantee that a base context selected for replication has not been corrupted after it has been acknowledged, or that it is still part of the state managed by the decompressor when the IR-CR will be received.
また、これはフィードバックチャネルが存在しない場合、コンプレッサは、コンテキストレプリケーション・メカニズムを使用することができないことを意味します。しかし、フィードバックチャネルの存在は、それが承認された後に、レプリケーションのために選択されたベースコンテキストが破損していないこと、またはそれはまだIR-CR意志解凍器によって管理された状態の一部であることを保証を提供することができないことに注意してください受信します。
More specifically, RFC 3095 [2] defines the context identifier (CID) as a reference to the state information (i.e., the context) used for compression and decompression. Multiple packet streams, each having its own context, may thus share a channel; and the CID space along with its representation within packet formats may be negotiated as part of the channel state. However, because RFC 3095 [2] does not explicitly define context state management between compressor and decompressor, in particular for connection-oriented flows (e.g., TCP), no more than a high degree of confidence can be achieved when selecting a base context.
より具体的には、RFC 3095 [2]の圧縮と解凍に使用状態情報（すなわち、コンテキスト）を基準として、コンテキスト識別子（CID）を定義します。複数のパケットストリームは、それぞれが独自のコンテキストを有し、従ってチャネルを共有することができます。パケットフォーマット内のその表現と共にCID空間は、チャネル状態の一部として交渉されてもよいです。 RFC 3095 [2]は、明示的に接続指向のフロー（例えば、TCP）のために、特にコンプレッサとデコンプレッサとの間のコンテキスト状態管理を定義していないので、ベースコンテキストを選択するときしかし、高い信頼度以下では達成できません。
In the case where feedback is not used by the decompressor, the compressor may have to periodically transit back to the IR state. In such a case, the same logic applies for the transition back to the higher order state via the CR state: a base context, previously acknowledged and suitable for replication, must be re-selected.
フィードバックは減圧装置によって使用されていない場合には、圧縮機は、背面IR状態に定期的に遷移する必要があります。このような場合には、同じロジックがバックCRの状態を経て、より高次の状態への遷移に適用されます。以前に認めおよび複製に適した、ベースコンテキスト、再選択しなければなりません。
The criteria for whether an existing context is a suitable base context for replication for a new flow are left to implementations.
既存のコンテキストが新たなフローの複製に適したベースコンテキストであるかどうかの基準は、実装に委ねられます。
Whenever the sequencing information from the last acknowledgement received is available, the compressor MAY use it to determine what fields can be replicated to avoid replicating any fields that have changed significantly from the state corresponding to the acknowledged packet.
最後に受信した確認応答からの配列情報が利用可能であるときはいつも、コンプレッサーは分野が確認パケットに対応する状態から大幅に変更されているすべてのフィールドを複製避けるために複製することができるかを決定するためにそれを使用することができます。
Transition to a higher order state can be carried out according to the optimistic approach principle. This means that the compressor may perform an upward state transition when it is fairly confident that the decompressor has received enough information to correctly decompress packets sent according to the higher compression state.
より高次の状態への遷移は、楽観的なアプローチ原則に従って行うことができます。減圧装置が正常より高い圧縮状態に応じて送信されたパケットを解凍するのに十分な情報を受信したことをかなり確信している場合、コンプレッサが上方の状態遷移を実行することができることを意味します。
In general, there are many approaches where the compressor can obtain such information. The compressor may obtain its confidence by sending several IR-CR packets with the same information.
一般に、圧縮機は、そのような情報を得ることができる多くのアプローチがあります。圧縮機は、同一の情報をいくつかのIR-CRパケットを送信することによって、その信頼性を得ることができます。
An ACK may be sent by the decompressor to indicate that a context has been successfully initialized during context replication.
ACKは、文脈が正常コンテキストの複製時に初期化されていることを示すために、解凍器によって送信されることがあります。
Upon reception of an ACK, the compressor may assume that the context replication procedure was successful and transit from its initial state (e.g., IR state) to a higher compression state.
ACKを受信すると、圧縮機は、コンテキスト複製手順が初期状態（例えば、IR状態）からより高い圧縮状態に成功し、通過したことを仮定してもよいです。
A STATIC-NACK sent by the decompressor may indicate that the decompressor could not initialize a valid context during context replication, and that the corresponding context has been invalidated.
解凍器により送信されたSTATIC-NACKは、解凍器は、コンテキストの複製時に有効なコンテキストを初期化できませんでしたことを示すことがあり、対応するコンテキストが無効にされていること。
Upon reception of a STATIC-NACK, the compressor MUST transit back to its initial no context state. The compressor SHOULD also refrain from sending IR-CR packets using the same base context, at least until an acknowledgement subsequent to the reception of the
STATIC-NACK、その初期ないコンテキスト状態に圧縮MUST走行バックを受信します。圧縮機はまた、少なくともの受信に続いて肯定応答されるまで、同じベース・コンテキストを使用してIR-CRパケットの送信を控えるべきです
STATIC-NACK makes this context suitable for replication (Section 3.3.3.1). The compressor SHOULD re-initialize the decompressor context using an IR packet.
STATIC-NACKは、複製（セクション3.3.3.1）のため、このコンテキストが適しています。圧縮機は、IRパケットを使用して、解凍器コンテクストを再初期化する必要があります。
A NACK sent by the decompressor may indicate that a valid context has been successfully initialized but that the decompression of one or more subsequent packets has failed.
解凍器により送信されたNACKは、有効なコンテキストが正常に初期化されたことが、1つのまたは複数の後続パケットの解凍に失敗したことを示すことができます。
Upon reception of a NACK, the compressor MAY assume that the static part of the decompressor context is valid, but that the dynamic part is invalid; the compressor may take actions accordingly.
NACKを受信すると、圧縮機は、減圧装置文脈の静的な部分が有効であることが、動的な部分が無効であることを仮定してもよいです。コンプレッサーはそれに応じて行動を取ることがあります。
Upon reception of an IR-CR packet, the decompressor first determines its content ([2], Section 5.2.6). The profile indicated in the IR-CR packet determines how it is to be processed. If the CRC (8-bit CRC) fails to verify the packet, the packet MUST be discarded.
IR-CRパケットを受信すると、減圧装置は最初にそのコンテンツ（[2]、セクション5.2.6）を決定します。 IR-CRパケットに示されたプロファイルは、それが処理される方法を決定します。 CRC（8ビットCRC）がパケットを検証に失敗した場合、パケットは廃棄されなければなりません。
If the profile as indicated in the IR-CR packet defines the use of the Base CID, and if its corresponding field is present within the packet format, this field is used to identify the base context; otherwise, the CID is used.
IR-CRパケットに示すように、プロファイルは、ベースCIDの使用を定義している場合、対応するフィールドは、パケットフォーマット内に存在する場合、及び、このフィールドは、ベース・コンテキストを識別するために使用されます。そうでない場合は、CIDが使用されています。
The decompressor creates a new context using the information present in the IR-CR packet together with the identified base context, and decompresses the original header.
減圧装置は、識別されたベースコンテキストと共にIR-CRパケット内に存在する情報を使用して新しいコンテキストを作成し、元のヘッダを解凍します。
The CRC calculated over the original uncompressed header and carried within the profile-specific part of the IR-CR headers (7-bit CRC) MUST be used to verify decompression.
CRCは、元の非圧縮ヘッダ上で計算及び解凍を検証するために使用されなければならないIR-CRヘッダ（7ビットのCRC）のプロファイル固有の部分内に運ば。
When the decompression is verified and successful, the decompressor initializes or updates the context with the information received in the current header. The decompressor SHOULD send an ACK when it successfully validates the context as a result of the decompression of one or more IR-CR packets.
解凍が検証に成功した場合には、減圧装置は現在のヘッダ内の受信された情報を用いてコンテキストを初期化または更新します。それが正常に一つ以上のIR-CRパケットの解凍の結果としてコンテキストを検証するとき解凍装置は、ACKを送信すべきです。
Otherwise, if the reconstructed header fails the CRC check, changes (either initialization or update) to the context MUST NOT be performed. When the decompressor fails to validate the header, actions as specified in Section 3.4.3 are taken.
再構成されたヘッダがCRCチェックに失敗した場合、そうでなければ、コンテキストの変更（初期化または更新のどちらか）を実行してはいけません。デコンプレッサはヘッダの検証に失敗した場合、セクション3.4.3で指定されたアクションが取られます。
For profiles supporting context replication, the feedback logic of a decompressor is similar to the logic used for context initialization, as described in [2].
[2]で説明されるようにコンテキストの複製を支持するプロファイルの場合、減圧装置のフィードバック論理回路は、コンテキストの初期化に使用されるロジックに類似しています。
Specifically, when the decompressor fails to validate the context following the decompression of one or more initial IR-CR packets, it MUST invalidate the context and remain in its initial state. In addition, the decompressor SHOULD send a STATIC-NACK. In particular, a decompressor implementation performing strict memory management, such as deleting context state information when a connection-oriented flow (e.g., TCP) is known to have terminated, SHOULD send STATIC-NACK in this case. Otherwise, there is a risk that the compressor will maintain a specific CID as a potential candidate for a later replication attempt, while actually there is insufficient state left in the decompressor for this CID to act as a Base CID.
減圧装置は、1つまたは複数の初期IR-CRパケットの解凍次のコンテキストの検証に失敗した場合に具体的には、コンテキストを無効にし、その初期状態のままでなければなりません。また、デコンプレッサは、STATIC-NACKを送るべきです。具体的には、減圧装置の実装は、このような接続指向の流れ（例えば、TCP）が終了したことが知られているコンテキスト状態情報を削除するように、厳密なメモリ管理を実行する、この場合にはSTATIC-NACKを送信すべきです。そうでなければ、基本CIDとして作用するように、このCIDのための減圧装置に残さ実際不十分な状態があるが、圧縮機は、後で複製試行のための潜在的な候補として特定のCIDを維持するおそれがあります。
If the context has been successfully validated from the decompression of one or more initial IR-CR packets, the decompressor SHOULD send a NACK when it fails to verify the context following the decompression of one or more subsequent IR-CR packets.
コンテキストが正常に一つ又は複数の初期IR-CRパケットの解凍の検証された場合には、1つまたは複数の後続IR-CRパケットの解凍次のコンテキストを確認するために失敗した場合、デコンプレッサは、NACKを送信すべきです。
The decompressor SHOULD use the CRC option (see [2], Section 5.7.6.3) when sending feedback corresponding to an IR or an IR-CR packet.
IRまたはIR-CRパケットに対応するフィードバックを送信するときにデコンプレッサは、（[2]、セクション5.7.6.3を参照）CRCオプションを使用すべきです。
The format of the IR-CR packet has been designed under the following constraints:
IR-CRパケットのフォーマットは、以下の制約の下で設計されています：
a) it must be possible to either overwrite a CID during context
replication, or to use a different CID than the Base CID for the
replicated context;
b) it must be possible to selectively include or exclude from the
packet format some fields that may be replicable;
c) it must be possible for some fields that may be replicable to be
represented within the packet format using either a compressed or
an uncompressed form;
d) it must be possible for the decompressor to verify the success of
the replication procedure;
e) it is anticipated that profiles, other than ROHC-TCP [3], will
also define support for context replication. Therefore it is
desirable that the packet format be profile independent.
The IR packet, as defined in [2], is used to communicate static and/or dynamic parts of a context, and typically initialize the context. For example, the static and dynamic chains of IR packets may contain an uncompressed representation of the original header.
IRパケットは、[2]で定義されるように、コンテキストの静的および/または動的部品を通信するために使用される、典型的にコンテキストを初期化しています。例えば、IRパケットの静的および動的な鎖は元のヘッダーの非圧縮表現を含むことができます。
The IR packet format includes an 8-bit CRC, calculated over the initial part of the IR packet. This CRC is meant to protect any information that initializes the context. In particular, its coverage always includes any CID information as well as the profile used to interpret the remainder of the IR packet.
IRパケットフォーマットは、IRパケットの最初の部分にわたって計算さ8ビットのCRCを含みます。このCRCは、コンテキストを初期化する任意の情報を保護するためのものです。具体的には、そのカバレッジは常にCID情報ならびにIRパケットの残りの部分を解釈するために使用されるプロファイルを含みます。
The purpose of the 8-bit CRC is to ensure the integrity of the IR header itself. Profiles may extend the coverage of this CRC to include the entire IR header, thus allowing the verification of the integrity of the entire uncompressed header. However, because the format of the IR packet is common to all ROHC profiles and verified as part of the initial processing of a ROHC decompressor (see [2], Section 5.2.6.), profiles may not redefine this CRC beyond the extent of its coverage.
8ビットCRCの目的は、IRヘッダ自体の完全性を保証することです。プロファイルは、このように全体の非圧縮ヘッダの完全性の検証を可能にする、全体IRヘッダを含めるには、このCRCの適用範囲を拡張することができます。 IRパケットのフォーマットは、すべてのROHCプロファイルに共通であり、ROHCデコンプレッサの初期処理の一部として検証しかし、（[2]、セクション5.2.6。参照）、プロファイルはの範囲を超えて、このCRCを再定義しなくてもよいですその報道。
RFC 3095 [2] also defines a 3-bit CRC and a 7-bit CRC for compressed headers, used to verify proper decompression and validate the context. This type of CRC is calculated over the original uncompressed header, as it is not sufficient to protect only the compressed data being exchanged between compressor and decompressor for the purpose of ensuring a robust reconstruction of the original header.
RFC 3095 [2]また、3ビットのCRCと適切な減圧を確認し、コンテキストを検証するために使用される圧縮ヘッダーの7ビットのCRCを、定義します。元のヘッダーのロバストな復元を確保するために圧縮と解凍器との間で交換されるだけ圧縮されたデータを保護するのに十分でないようにCRCのこのタイプは、元の非圧縮ヘッダに対して計算されます。
Thus, there is a clear distinction in purpose between the 8-bit CRC found in the IR packet and the 3-bit or 7-bit CRC found in compressed headers. With context replication, where the IR-CR packet may contain both compressed as well as uncompressed information and omit entirely replicable fields, this distinction in no longer present.
従って、IRパケット及び圧縮ヘッダーに見られる3ビット又は7ビットのCRCに見出される8ビットのCRCとの間の目的の明確な区別があります。 IR-CRパケットはもはや存在では、この区別を両方の圧縮ならびに圧縮されていない情報を含み、完全に複製フィールドを省略することができるコンテキストの複製、を有します。
Profiles supporting context replication MUST define a CRC over the original uncompressed header as part of the profile-specific information in the IR-CR packet. This is necessary to allow a decompressor to verify that the replication process has succeeded.
コンテキスト複製を支持プロファイルはIR-CRパケットにおけるプロファイル固有情報の一部として、元の非圧縮ヘッダ上CRCを定義しなければなりません。これは、デコンプレッサは、レプリケーション・プロセスが成功したことを確認することができるようにする必要があります。
The 7-bit CRC in the IR-CR packet is calculated over all octets of the entire original header, before replication, in the same manner as described in Section 5.9.2 of [2].
セクション5.9.2に記載したようにIR-CRパケットに7ビットCRCは、同様に、複製の前に、全体のオリジナルヘッダの全てのオクテットに渡って計算される[2]。
The initial content of the CRC register is to be preset to all 1's. The CRC polynomial used for the 7-bit CRC in the IR-CR is:
CRCレジスタの初期の内容は、すべて1年代にプリセットされます。 IR-CR 7ビットのCRCに使用CRC多項式です。
C(x) = 1 + x + x^2 + x^3 + x^6 + x^7
C（x）= 1 + X + X ^ 2 + X ^ 3 + X ^ 6 + X ^ 7
The coverage of the 8-bit CRC in the IR-CR packet is not profile dependent, as opposed to the ROHC IR(-DYN) packet (see [2], Sections 5.2.3 and 5.2.4). It MUST cover the entire packet, excluding the payload. In particular, this includes the CID or any add-CID octet as well as the Base CID field, if present. For profiles that define the usage of the Base CID within the packet format of the IR-CR as optional, this CRC MUST also cover the information used to indicate the presence of this field within the packet.
IR-CRパケットの8ビットのCRCの適用範囲は、（[2]、セクション5.2.3および5.2.4参照）ROHC IR（-DYN）パケットとは対照的に、依存プロファイルはありません。これは、ペイロードを除く、パケット全体をカバーしなければなりません。存在する場合には特に、これは、CIDまたは任意のアドオンCIDオクテット並びに基本CIDフィールドを含みます。オプションとして、IR-CRのパケットフォーマット内の基本CIDの使用法を定義するプロファイルの場合、このCRCは、パケット内のこのフィールドの存在を示すために使用される情報をカバーしなければなりません。
The initial content of the CRC register is to be preset to all 1's. The CRC polynomial used for the 8-bit CRC in the IR-CR is:
CRCレジスタの初期の内容は、すべて1年代にプリセットされます。 IR-CR 8ビットのCRCに使用CRC多項式です。
C(x) = 1 + x + x^2 + x^8
C（x）= 1 + X + X ^ 2 + X ^ 8
The context replication mechanism requires a dedicated IR packet format that uniquely identifies the IR-CR packet. This packet communicates the static and the dynamic parts of the replicated context. It may also communicate a reference to a base context.
コンテキスト複製機構は、一意IR-CRパケットを識別する専用のIRパケットフォーマットを必要とします。このパケットは、静的および複製コンテキストの動的部分を通信します。また、ベースコンテキストへの参照を通信することができます。
With consideration to the extensibility of the IR packet type defined in [2], support for replication can be added using the profile-specific part of the IR packet. Note that there is one bit, (x), left in the IR header for "Profile specific information". The definition of this bit is profile specific. Thus, profiles supporting context replication MAY use this bit as a flag indicating whether the packet is an IR packet or an IR-CR packet. Note also that profiles may define an alternative method to identify the IR-CR packet within the profile-specific information, instead of using this bit.
[2]で定義されたIRパケットタイプの拡張性を考慮して、複製のためのサポートは、IRパケットのプロファイル固有部分を使用して追加することができます。 1ビットがあることに注意してください、（X）、「プロファイル固有情報」のIRヘッダに残さ。このビットの定義は、プロファイル固有のものです。したがって、コンテキスト複製を支持プロファイルは、パケットがIRパケットまたはIR-CRパケットであるか否かを示すフラグとして、このビットを使用するかもしれません。プロファイルが代わりにこのビットを使用する、プロファイル固有情報内のIR-CRパケットを識別するための別の方法を定義してもよいことにも留意されたいです。
The IR-CR header associates a CID with a profile, and initializes the context using the context replication mechanism. It is not recommended to use this packet to repair a damaged context.
IR-CRヘッダープロファイルとCIDを関連付け、コンテキストレプリケーション・メカニズムを使用してコンテキストを初期化します。損傷を受けたコンテキストを修復するために、このパケットを使用することは推奨されません。
The IR-CR has the following general format:
IR-CRは、以下の一般的なフォーマットを有します。
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 x | IR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ Profile-specific information / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -
x: Profile-specific information. Interpreted according to the profile indicated in the Profile field.
X：プロファイル固有の情報。プロファイルフィールドに示されたプロファイルに従って解釈。
Profile: The profile to be associated with the CID. In the IR-CR packet, the profile identifier is abbreviated to the 8 least significant bits (LSBs). It selects the highest-number profile in the channel state parameter PROFILES that matches the 8 LSBs given (see also [2]).
プロフィール：CIDに関連付けするプロファイル。 IR-CRパケットに、プロファイル識別子は、8つの最下位ビット（LSB）と略記します。それは与えられた8つのLSBと一致したチャネル状態パラメータプロファイルにおける最高数のプロファイルを選択する（参照[2]）。
CRC: 8-bit CRC computed using the polynomial of Section 3.5.1.2.
CRC：8ビットCRCは、セクション3.5.1.2の多項式を用いて計算しました。
Profile-specific information: The contents of this part of the IR-CR packet are defined by the individual profiles. This information is interpreted according to the profile indicated in the Profile field. It MUST include a 7-bit CRC over the original uncompressed header using the polynomial of Section 3.5.1.1. It also includes the static and dynamic subheader information used for replication; thus, which header fields are replicated and their respective encoding methods are outside the scope of this document.
プロファイル固有の情報：IR-CRパケットのこの部分の内容は、個々のプロファイルによって定義されます。この情報は、プロファイルフィールドに示されたプロファイルに従って解釈されます。これは、セクション3.5.1.1の多項式を用いて、元の非圧縮ヘッダオーバー7ビットのCRCを含まなければなりません。それはまた、複製のために使用される静的及び動的サブヘッダの情報を含みます。従って、どのヘッダフィールドが複製され、それらのそれぞれの符号化方法は、この文書の範囲外です。
Payload: The payload of the corresponding original packet, if any.
ペイロード：対応するオリジナルのパケットのペイロード（もしあれば）。
The Base CID within the packet format of the IR-CR may be assigned a different value than the context identifier associated with the new flow (i.e., BCID != CID); otherwise, the base context is overwritten with the new context by the replication process.
IR-CRのパケットフォーマット内の基本CIDは、新たなフロー（！すなわち、BCID = CID）に関連付けられたコンテクスト識別子とは異なる値を割り当てることができます。それ以外の場合は、ベースコンテキストは、複製プロセスによって新しいコンテキストで上書きされます。
When the channel uses small CIDs, a four-bit field within the packet format of the IR-CR minimally represents the BCID with a value from 0 to 15. In particular, the four bits of Add-CID used with small CIDs [2] are not needed for the BCID, as this information is already provided by the CID of the IR-CR packet itself. When large CIDs are used, the BCID is represented in the IR-CR with one or two octets, and it is coded in the same way as a large CID [2].
チャネルが小さなCIDを使用する場合、IR-CRの最小のパケットフォーマット内の4ビットのフィールドは、特に0〜15の値でBCIDを表し、アドインCIDの4ビットは、小のCIDと共に使用[2]この情報は既にIR-CRパケット自体のCIDによって提供されるように、BCIDのために必要とされません。大型のCIDが使用される場合、BCIDは、1つのまたは2つのオクテットとIR-CRで表され、それは、大きなCIDと同じ方法で符号化されている[2]。
This document adds an alternative mechanism for ROHC profiles to increase the compression efficiency when initializing a new context, by reusing information already existing at the decompressor. This is achieved by introducing new state transition logic, new feedback logic, and a new packet type -- all based on logic and packet formats already defined in RFC 3095 [2].
この文書は、新しいコンテキストを初期化するとき解凍器で既存すでに情報を再利用することにより、圧縮効率を高めるためにROHCプロファイル用の代替メカニズムが追加されます。全て既にRFC 3095で定義されたロジックと、パケットフォーマットに基づいて[2] - これは、新しい状態遷移ロジック、新しいフィードバック論理回路、及び新しいパケットタイプを導入することによって達成されます。
In this respect, this document is not believed to bring any additional weakness to potential attacks to those already listed in [2]. However, it does increase the potential impacts of these attacks by creating dependencies between multiple contexts. Specifically, corruption of one context can fail compressor attempts to initialize another context at the decompressor, or to propagate to another context, if the compressor uses a corrupted context as a base for replication.
この点で、この文書は、すでに[2]に記載されているものに潜在的な攻撃に任意の追加の弱さをもたらすとは考えられません。しかし、それは複数のコンテキスト間の依存関係を作成することにより、これらの攻撃の潜在的な影響を増加させません。具体的には、あるコンテキストの破損は、圧縮機は、複製のためのベースとして破損したコンテキストを使用している場合、デコンプレッサで別のコンテキストを初期化する、または別のコンテキストに伝達する圧縮機の試行に失敗することができます。
The author would like to thank Richard Price, Kristofer Sandlund, Fredrik Lindstroem, Zhigang Liu, and HongBin Liao for valuable input, as well as Mark West and Lars-Erik Jonsson who also served as committed working group document reviewers.
著者はまた、コミットワーキンググループ文書の校閲を務めたマーク・西とラース・エリックジョンソンの貴重な入力のためのリチャード価格、クリストファーSandlund、フレドリックLindstroem、志剛劉、とHongbinは遼に感謝し、同様にしたいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[2]ボルマン、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月。
[3] Pelletier, G., Jonsson, L-E., Sandlund, K., and M. West, "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)", Work in Progress, July 2005.
[3]ペルティエ、G.、ジョンソン、LE、Sandlund、K.、およびM.西、 "ロバストヘッダ圧縮（ROHC）：TCP / IPのためのプロファイル（ROHC-TCP）"。進歩、2005年7月、ワーク。
[4] Jonsson, L-E., "RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression", RFC 4163, August 2005.
[4]ジョンソン、L-E、 "ロバストヘッダ圧縮（ROHC）：TCP / IPヘッダー圧縮の要件"、RFC 4163、2005年8月。
[5] West, M. and S. McCann, "TCP/IP Field Behavior", Work in Progress, October 2004.
[5]西、M.とS.マッキャン、 "TCP / IPフィールドの動作"、進歩、2004年10月に作業。
[6] Finking, R. and G. Pelletier, "Formal Notation for Robust Header Compression (ROHC-FN)", Work in Progress, June 2005.
[6] Finking、R.及びG.ペルティエ、 "ロバストヘッダ圧縮（ROHC-FN）のための正式な表記法"、進歩、2005年6月ワーク。
Appendix A: General Format of the IR-CR Packet (Informative)
付録A：IR-CRパケットの一般形式（参考情報）
A.1. General Structure (Informative)
A.1。一般構造（参考情報）
This section provides an example of the format of the profile-specific information within the general format of the IR-CR.
このセクションでは、IR-CRの一般的なフォーマット内プロファイル固有情報のフォーマットの例を提供します。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| |
/ replication base information / variable length
| |
+---+---+---+---+---+---+---+---+
| |
/ replication information / variable length
| |
- - - - - - - - - - - - - - - -
Replication base information: The contents of this part of the IR-CR packet are defined by the individual profiles. This information is interpreted according to the profile indicated in the Profile field. It MUST include a 7-bit CRC over the original uncompressed header using the polynomial of Section 3.4.1.1. See Appendix A.2.
レプリケーションベース情報：IR-CRパケットのこの部分の内容は、個々のプロファイルによって定義されます。この情報は、プロファイルフィールドに示されたプロファイルに従って解釈されます。これは、セクション3.4.1.1の多項式を用いて、元の非圧縮ヘッダオーバー7ビットのCRCを含まなければなりません。付録A.2を参照してください。
Replication information: The contents of this part of the IR-CR packet are also defined by the individual profiles. This part contains the static and dynamic subheader information used for replication. How this information is structured is profile specific; profiles may define the contents of this field using a chain structure (static and dynamic replication chains) or by defining header formats for replication (e.g., ROHC-TCP [3]).
レプリケーション情報：IR-CRパケットのこの部分の内容は、個々のプロファイルによって定義されます。この部分は、レプリケーションのために使用される静的および動的なサブヘッダ情報が含まれています。プロファイルの特定はどのようにこの情報が構成されています。プロファイルは、鎖状構造（静的および動的な複製鎖）を使用してこのフィールドのまたは複製のためのヘッダ・フォーマットを定義することにより、コンテンツを定義することができる（例えば、ROHC-TCP [3]）。
A.2. Profile-Specific Replication Information (Informative)
A.2。プロファイル固有のレプリケーション情報（参考情報）
This section provides a more detailed example of the possible format of the replication information field described in Appendix A.1:
このセクションでは、付録A.1に記載のレプリケーション情報フィールドの可能なフォーマットの詳細な例を提供します。
+---+---+---+---+---+---+---+---+
| B | CRC7 | 1 octet
+---+---+---+---+---+---+---+---+
| | present if B = 1,
/ Base CID / 1 octet if for small CIDs, or
| | 1-2 octets if for large CIDs
+---+---+---+---+---+---+---+---+
B: B = 1 indicates that the Base CID field is present.
B：B = 1基本CIDフィールドが存在することを示します。
CRC7: The CRC over the original, uncompressed, header. This 7-bit CRC is computed according to Section 3.4.1.1.
CRC7：オリジナルの、圧縮されていない、ヘッダ上CRC。この7ビットのCRCは、セクション3.4.1.1に従って計算されます。
Base CID: The CID identifying the base context used for replication.
ベースCID：複製に使用されるベースコンテキストを識別するCID。
Appendix B: Inter-Profile Context Replication (Informative)
付録B：インタープロフィール文脈模写（参考情報）
Context replication as defined in this document does not explicitly support the concept of context replication between profiles. However, it might be of interest when developing new compression profiles.
この文書で定義されているコンテキストの複製は、明示的にプロファイル間のコンテキストの複製の概念をサポートしていません。新しい圧縮プロフィールを開発するときしかし、それは興味があるかもしれません。
Inter-profile context replication would require that the decompressor have access to data structures from the base context, which belongs to a profile different than the profile using replication. This information would have to be made available in a format consistent with the data structures and encoding method(s) in use for all header fields that are being replicated.
インタープロファイルのコンテキストの複製は、デコンプレッサは、レプリケーションを使用してプロファイルとは異なるプロファイルに属しているベースコンテキストからのデータ構造へのアクセスを持っていることを必要とするであろう。この情報は、複製されているすべてのヘッダフィールドに使用されているデータ構造及び符号化方式（S）と一致する形式で利用可能にしなければなりません。
B.1. Defining Support for Inter-Profile Context Replication
B.1。インタープロフィール文脈模写のサポートを定義します
A ROHC profile describes how to compress a specific protocol stack, and includes one or more sets of packet formats. The packet formats will typically compress the protocol headers relative to a context of field values from previous headers in a flow. This context may also contain some control data. Thus, the packet formats specify a mapping between the uncompressed and compressed version of a protocol field.
ROHCプロファイルには、特定のプロトコル・スタックを圧縮する方法について説明し、パケット・フォーマットの1つまたは複数のセットを含みます。パケットフォーマットは、典型的には、フロー内の前のヘッダからフィールド値のコンテキストに対するプロトコルヘッダを圧縮します。このコンテキストはまた、いくつかの制御データを含んでいてもよいです。したがって、パケットフォーマットは、プロトコルフィールドの非圧縮および圧縮バージョンとの間のマッピングを指定します。
This mapping is achieved through the use of one or more encoding methods, which are simply functions applied to compress or decompress a field. An encoding method is in turn defined using a name, a set of function parameters, and a formal expression (i.e., using the ROHC-FN [6]) or a textual description (i.e., a la RFC 3095 [2]) of its behaviour.
このマッピングは、単にフィールドを圧縮または圧縮解除するために適用される関数である1つの以上の符号化方法を使用することによって達成されます。符号化方法は、順番に名前、関数パラメータのセット、および正式な表現使用して定義されている（使用して、すなわちROHC-FN [6]）またはテキスト記述（すなわち、ラRFC 3095 [2]）のその動作。
To compress one or more fields of a specific protocol stack, different profiles may define their packet formats using different encoding methods, or using a variant of a similar technique. A typical example of the latter is list compression, such as used for IP extension headers. This implies that context entries for a field belonging to a specific protocol stack may differ in their content, representation, and structure from one profile to another.
特定のプロトコル・スタックの1つ以上のフィールドを圧縮するために、異なるプロファイルは、異なる符号化方法を用いて、または同様の技術の変形を使用してパケット・フォーマットを定義することができます。後者の典型的な例は、IP拡張ヘッダのために使用されるような、リストの圧縮です。これは、特定のプロトコルスタックに属するフィールドのコンテキストエントリは別のプロファイルから、その内容、表現、及び構造が異なっていてもよいことを意味します。
As a consequence of the above, a profile that supports context replication can only use a base context from another profile explicitly supporting the concept of a base context. That is, existing profiles not supporting this concept must be updated first to ensure that they can export the necessary context data entries that use a meaningful representation during replication.
上記の結果として、コンテキストのレプリケーションをサポートしているプロファイルは、明示的にベースコンテキストの概念をサポートしている別のプロファイルからのベースコンテキストを使用することができます。それは、この概念をサポートしていない既存のプロファイルは、それらが複製の際に意味のある表現を使用して、必要なコンテキストデータエントリをエクスポートできることを保証するために、最初に更新されなければなりません。
Specifically, inter-profile context replication would require that decompressor implementations (including existing ones) of other profiles be updated when adding support for a profile that uses context replication. Therefore, inter-profile context replication cannot be seen as an implementation-specific issue.
具体的には、インタープロファイルコンテキスト複製は、コンテキストの複製を使用するプロファイルのサポートを追加するときに更新される他のプロファイルの（既存のものを含む）は減圧装置の実装を必要とするであろう。したがって、インタープロファイルコンテキストの複製は実装固有の問題として見ることができません。
The compressor must know if the decompressor supports inter-profile context replication before initiating the procedure. The compressor must also know which contexts (belonging to which profile) may be used as a base context. Therefore, a compressor cannot initiate context replication using a base context belonging to a different profile, unless that profile explicitly provides the proper mapping for its context entries or that profile is defined formally using ROHC-FN [6] in a manner that makes both profiles compatible. The set of profiles negotiated for the channel (see also RFC 3095 [2]) can then be used to determine if a context for a specific profile can be used as a base context.
デコンプレッサは、手順を開始する前に、間プロファイルのコンテキストのレプリケーションをサポートしている場合、コンプレッサは知っている必要があります。圧縮機は、ベースコンテキストとして使用することができるコンテキスト（どのプロファイルに属する）を知る必要があります。そのプロファイルは、明示的にコンテキスト・エントリのための適切なマッピングを提供する、またはそのプロファイルがROHC-FNを用いて正式に定義されていない限りそのため、圧縮機は両方のプロファイルを作るように[6]、別のプロファイルに属する基地コンテキストを使用して、コンテキストの複製を開始できません互換性。チャネルのために交渉プロファイルのセットは、特定のプロファイルのコンテキストは、ベースコンテキストとして使用することができるかどうかを決定するために使用することができる（[2] RFC 3095も参照します）。
B.2. Compatibility between Different Profiles (Informative)
B.2。異なるプロファイル間の互換性（参考情報）
Compatibility between profiles, when replicating a field for a particular protocol stack, can be expressed as follow: a field that is compressed by different profiles is compatible for inter-profile replication if it is defined in the set of packet formats using the same mapping function between its uncompressed and compressed version.
それが同一のマッピング関数を使用して、パケットフォーマットのセットで定義されている場合、異なるプロファイルによって圧縮されたフィールドは、インタープロファイルの複製のために互換性がある：特定のプロトコルスタックのためのフィールドを複製する際にプロファイル間の互換性は、以下のように表すことができます。その非圧縮と圧縮バージョン間。
For example, the IP Destination Address field which, based on the packet formats and compression strategies defined in RFC 3095 [2], is implicitly compressed using an encoding method equivalent to the static() method defined in ROHC-FN [6].
例えば、RFC 3095で定義されたパケットフォーマットと圧縮戦略に基づいて、IP宛先アドレスフィールド[2]、暗黙ROHC-FNで定義された静的（）メソッド[6]に相当する符号化方法を使用して圧縮されます。
In particular, for profiles that define their packet formats using a formal notation such as ROHC-FN [6], two different encoding methods may not have the same name. Thus, a field from a protocol stack is said to be compatible for replication between two different profiles if it has an equivalent definition within respective packet formats.
特に、そのようなROHC-FNのような正式な表記法を使用してパケット・フォーマットを定義するプロファイルの[6]、二つの異なる符号化方式は、同一の名前を有していなくてもよいです。したがって、プロトコルスタックからのフィールドは、それぞれのパケットフォーマット内の同等の定義を有する場合、2つの異なるプロファイル間の複製のために互換性があると言われています。
Author's Address
著者のアドレス
Ghyslain Pelletier Box 920 Ericsson AB SE-971 28 Lulea, Sweden
GhyslainペルティエエリクソンABボックス920 SE-971 28ルーレオ、スウェーデン
Phone: +46 8 404 29 43 Fax: +46 920 996 21 EMail: ghyslain.pelletier@ericsson.com
電話：+46 8 404 29 43ファックス：+46 920 996 21 Eメール：ghyslain.pelletier@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。