[要約] RFC 4164は、ROHCプロファイルのためのコンテキスト複製に関する技術仕様です。その目的は、ROHCプロファイルの効率的なヘッダ圧縮を実現するために、コンテキスト情報の複製と同期を提供することです。
Network Working Group G. Pelletier
Request for Comments: 4164 Ericsson
Category: Standards Track August 2005
RObust Header Compression (ROHC): Context Replication for ROHC Profiles
堅牢なヘッダー圧縮（ROHC）：ROHCプロファイルのコンテキスト複製
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).
Copyright（c）The Internet Society（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で指定されているように、コンテキストレプリケーションを定義します。これは、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.
多くの場合、同じコンプレッサー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.
コンテキストレプリケーションにより、IPソースや宛先アドレス（IPv6用の16オクテット）などのヘッダーフィールドを、レプリケーション用に特別に定義された特別な開始と更新（IR）パケットタイプ内で省略できます。また、ソースポートや宛先ポートなどの他のフィールドを、ヘッダー圧縮フローの最初のパケットから圧縮フォームで省略または送信できます。
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.
このメカニズムをサポートするプロファイルの場合、コンプレッサーは、既存のコンテキストのコピー、つまり基本コンテキストのコピーを再利用または作成して、複製されたコンテキストを作成することにより、コンテキスト複製を実行します。次に、複製されたコンテキストが更新され、新しいフローのヘッダーフィールドに一致します。次に、コンプレッサーは、複製されたコンテキストを作成するときに更新する必要があるフィールドのデータとともに、選択したベースコンテキストへの参照を含むパケットをDecompressorに送信します。最後に、減圧器は、受信したパケットからの非圧縮および圧縮データとともに、基本コンテキストへの参照に基づいて複製されたコンテキストを作成します。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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 Byte Order and the type of behavior of the field, respectively. Another example is the parameter indicating the mode of operation [2].
それらを使用して、圧縮および減圧の動作、特に使用するパケット形式のセットを制御できます。制御フィールドはプロファイル固有です。このようなフィールドの例には、NBOおよびRNDフラグ[2]が含まれます。これは、IP-IDフィールドがネットワークバイトの順序であり、フィールドの動作の種類を示しています。別の例は、動作モードを示すパラメーターです[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は、IRパケット[2]とは異なります。その目的は、基本コンテキストのどの部分が複製されているかを完全に指定し、新しいコンテキストを作成するために必要な補完的な情報を伝えることです。このため、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パケット（IR-CR）を定義します。これは、新しいコンテキストを初期化するために使用できます。その結果、IR-CRパケットの使用に必要な追加のロジックを含むコンプレッサー状態マシンにコンテキストレプリケーション（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.
コンテキスト複製のサポートを定義するプロファイルの場合、コンプレッサーは、既存のコンテキストを複製のベースコンテキストとして選択できる場合、IR状態からCR状態に直接通過する場合があります。これにより、コンテキスト確立手順中に送信されたIR/IR-DynパケットをIR-CRパケットに効果的に置き換えます。
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).
コンプレッサーは常に低い圧縮状態（IR）で始まり、コンプレッサーが圧縮されるフローに適したベースコンテキストを選択できるという制約の下で、コンテキスト複製状態（CR）にトランジットします（セクション3.3.3.1も参照）。
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.
CR状態からより高い圧縮状態（[3]のCO状態など）への移行は、分解器から受け取った楽観的なアプローチの原則またはフィードバックに基づいています。
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状態と高次の状態の間の既存の遷移には影響しません。
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 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.
- ベースコンテキストの可用性 - 減圧装置からの肯定的なフィードバック（謝辞-ACK） - 減圧装置からのネガティブフィードバック（ネガティブアクック - NACKS） - パケットコンテキストのエラーのない減圧に関する信頼レベルは、リンク上で動作するように設計されています。フィードバックチャネルが利用可能です。これは、新しいコンテキストの作成に使用される情報がコンプレッサーと減圧器の間で同期されるようにするために必要です。さらに、コンテキストレプリケーションは、IR状態への移行およびより高い圧縮率のある状態へのオプションの改善された前方遷移のために、減圧器からコンプレッサーへのフィードバックを使用する場合があります。
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で指定されています。フィードバック情報は、フィードバック1とフィードバック2の2つの可能な形式を使用して構成されています。特に、フィードバック-2は、ACK、NACK、または静的ナックの3つの可能なタイプのフィードバック情報のいずれかを伝えることができます。
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.
コンプレッサーは、適切なベースコンテキストを識別できる場合に、IR状態からCR状態への移行を開始する場合があります。この遷移を実行するために、コンプレッサーは、以前にdecompressorによって基本コンテキストとして認められていたコンテキストを選択します。選択されたコンテキストは、フィードバックメッセージのCRCオプション（[2]、セクション5.7.6.3も参照）を使用して減圧器によって確認されている必要があります。複製されるベースコンテキストの静的部分は、減圧器によって認められている必要があり、ベースコンテキストは複製時間に有効でなければなりません。
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がいつ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.
減圧器によって送信された静的ナックは、コンプレッサーがコンテキスト複製中に有効なコンテキストを初期化できなかったこと、および対応するコンテキストが無効になっていることを示している可能性があります。
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 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の受信に続いてこのコンテキストが複製に適しているようになるまで、同じベースコンテキストを使用してIR-CRパケットを送信することを控える必要があります（セクション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.
元の非圧縮ヘッダーを介して計算され、IR-CRヘッダー（7ビットCRC）のプロファイル固有の部分内で運ばれた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.
減圧が検証され成功すると、減圧装置は現在のヘッダーで受信した情報とコンテキストを初期化または更新します。減圧器は、1つ以上の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パケットの減圧に続いてコンテキストを検証できない場合、コンテキストを無効にし、初期状態にとどまる必要があります。さらに、減圧器は静的ナックを送信する必要があります。特に、接続指向のフロー（TCPなど）が終了したことが知られている場合にコンテキスト状態情報を削除するなど、厳格なメモリ管理を実行する減圧装置の実装は、この場合は静的ナックを送信する必要があります。それ以外の場合、コンプレッサーが後の複製試行の潜在的な候補として特定の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.
コンテキストが1つ以上の初期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パケットに対応するフィードバックを送信するときに、CRCオプション（[2]、セクション5.7.6.3を参照）を使用する必要があります。
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.
[2]で定義されているIRパケットは、コンテキストの静的部分および/または動的部分を通信し、通常はコンテキストを初期化するために使用されます。たとえば、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ヘッダー自体の完全性を確保することです。プロファイルは、このCRCのカバレッジを拡張してIRヘッダー全体を含めるため、非圧縮ヘッダー全体の完全性の検証を可能にする場合があります。ただし、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パケットで見つかった8ビットCRCと、圧縮ヘッダーで見つかった3ビットまたは7ビット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].
IR-CRパケットの7ビットCRCは、[2]のセクション5.9.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
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のカバレッジは、ROHC IR（-Dyn）パケットとは対照的に、プロファイルに依存しません（[2]、セクション5.2.3および5.2.4を参照）。ペイロードを除く、パケット全体をカバーする必要があります。特に、これには、存在する場合は、CIDまたはADD-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
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パケットのプロファイル固有の部分を使用して複製のサポートを追加できます。「プロファイル固有の情報」のために、IRヘッダーに残された（x）が1つあることに注意してください。このビットの定義はプロファイル固有です。したがって、コンテキストレプリケーションをサポートするプロファイルは、このビットをフラグとして使用して、パケットが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：セクション3.5.1.2の多項式を使用して計算された8ビットCRC。
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ビットのADD-CID [2]この情報はすでにIR-CRパケット自体のCIDによって提供されているため、BCIDには必要ありません。大きなCIDを使用すると、BCIDはIR-CRで1つまたは2つのオクテットで表され、大きな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].
このドキュメントは、decompressorに既存の情報を再利用することにより、新しいコンテキストを初期化するときに圧縮効率を高めるために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.
この点で、この文書は、既にリストされている攻撃に潜在的な攻撃にさらなる弱点をもたらすとは考えられていません。ただし、複数のコンテキスト間で依存関係を作成することにより、これらの攻撃の潜在的な影響を高めます。具体的には、1つのコンテキストの破損は、コンプレッサーが減圧器で別のコンテキストを初期化しようとするか、コンプレッサーが複製のベースとして破損したコンテキストを使用している場合、別のコンテキストに別のコンテキストを初期化しようとする可能性があります。
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.
著者は、リチャード・プライス、クリストファー・サンドランド、フレドリック・リンドストローム、Zhigang Liu、およびHongbin Liaoに貴重な入力をしてくれたこと、そしてコミットしたワーキンググループのドキュメントレビュー担当者を務めたMark WestとLars-Erik Jonssonに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Bormann、C.、Burmeister、C.、Degermark、M.、Fukushima、H.、Hannu、H.、Jonsson、L-E。、Hakenberg、R.、Koren、T.、Le、K.、Liu、Z。、Martensson、A.、Miyazaki、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH. Zheng、 "Robust Header圧縮（ROHC）：フレームワークと4つのプロファイル：RTP、UDP、ESP、および非圧縮」、RFC 3095、2001年7月。
[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] Pelletier、G.、Jonsson、L-E。、Sandlund、K。、およびM. West、「Robust Header Compression（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] Jonsson、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] West、M。およびS. McCann、「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. Pelletier、「堅牢なヘッダー圧縮の正式な表記（ROHC-FN）」、2005年6月、進行中の作業。
Appendix A: General Format of the IR-CR Packet (Informative)
付録A：IR-CRパケットの一般的な形式（有益）
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]）を使用して、このフィールドの内容を定義できます。
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.
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.
間隔のコンテキストレプリケーションでは、減圧装置がレプリケーションを使用してプロファイルとは異なるプロファイルに属するベースコンテキストからデータ構造にアクセスできるようにする必要があります。この情報は、複製されているすべてのヘッダーフィールドで使用されているデータ構造とエンコード方法と一致する形式で利用できるようにする必要があります。
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]を使用）またはテキストの説明（つまり、A LA 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]を使用して正式に定義されていない限り、異なるプロファイルに属するベースコンテキストを使用してコンテキストレプリケーションを開始することはできません。互換性。チャネルにネゴシエートされたプロファイルのセット（RFC 3095 [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 [2]で定義されているパケット形式と圧縮戦略に基づいているIP宛先アドレスフィールドは、ROHC-FN [6]で定義されたstatic（）メソッドに相当するエンコードメソッドを使用して暗黙的に圧縮されます。
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つの異なるエンコーディング方法に同じ名前がない場合があります。したがって、プロトコルスタックからのフィールドは、それぞれのパケット形式内に同等の定義がある場合、2つの異なるプロファイル間の複製と互換性があると言われています。
Author's Address
著者の連絡先
Ghyslain Pelletier Box 920 Ericsson AB SE-971 28 Lulea, Sweden
Ghyslain Pelletier Box 920 Ericsson AB SE-971 28 Lulea、Sweden
Phone: +46 8 404 29 43
Fax: +46 920 996 21
EMail: ghyslain.pelletier@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。