Network Working Group L-E. Jonsson
Request for Comments: 3759 Ericsson
Updates: 3095 April 2004
Category: Informational
RObust Header Compression (ROHC):
Terminology and Channel Mapping Examples
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
This document aims to clarify terms and concepts presented in RFC 3095. RFC 3095 defines a Proposed Standard framework with profiles for RObust Header Compression (ROHC). The standard introduces various concepts which might be difficult to understand and especially to relate correctly to the surrounding environments where header compression may be used. This document aims at clarifying these aspects of ROHC, discussing terms such as ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts, and how these terms relate to other terms, like network elements and IP interfaces, commonly used, for example, when addressing MIB issues.
この文書は、RFC 3095 RFC 3095.に提示用語や概念を明確にすることを目的とロバストヘッダ圧縮（ROHC）のプロファイルでのProposed Standardフレームワークを定義します。標準は、理解し、特にヘッダ圧縮を使用することができる周囲の環境に正しく関連するのは困難かもしれない様々な概念を導入します。この文書では、これらの用語は、場合例えば、一般的に使用されるネットワーク要素とIPインタフェースのような、他の用語に関連するどのようなROHCインスタンス、ROHCチャンネル、ROHCフィードバック、およびROHCコンテキストなどの用語を議論、ROHCのこれらの側面を明らかにすることを目的とMIBの問題に取り組みます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. ROHC External Terminology. . . . . . . . . . . . . . . . . . . 6
3.1. Network Elements and IP Interfaces . . . . . . . . . . . 6
3.2. Channels . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. A Unidirectional Point-to-Point Link Example . . . . . . 8
3.4. A Bi-directional Point-to-Point Link Example . . . . . . 8
3.5. A Bi-directional Multipoint Link Example . . . . . . . . 9
3.6. A Multi-Channel Point-to-Point Link Example. . . . . . . 9
4. ROHC Instances . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. ROHC Compressors . . . . . . . . . . . . . . . . . . . . 11
4.2. ROHC Decompressors . . . . . . . . . . . . . . . . . . . 12
5. ROHC Channels. . . . . . . . . . . . . . . . . . . . . . . . . 13
6. ROHC Feedback Channels . . . . . . . . . . . . . . . . . . . . 14
6.1. Single-Channel Dedicated ROHC FB Channel Example . . . . 14
6.2. Piggybacked/Interspersed ROHC FB Channel Example . . . . 15
6.3. Dual-Channel Dedicated ROHC FB Channel Example . . . . . 16
7. ROHC Contexts. . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Implementation Implications. . . . . . . . . . . . . . . . . . 18
10. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
12. Informative References . . . . . . . . . . . . . . . . . . . . 19
13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20
In RFC 3095, the RObust Header Compression (ROHC) standard framework is defined, along with 4 compression profiles [RFC-3095]. Various concepts are introduced within the standard that are not all very extensively defined and described, which can easily be an obstacle when trying to understand the standard. This can especially be the case when one considers how the various parts of ROHC relate to the surrounding environments where header compression may be used.
RFC 3095においては、ロバストヘッダ圧縮（ROHC）標準フレームワークは4つの圧縮プロファイル[RFC-3095]と一緒に、定義されています。様々な概念は、標準を理解しようとしたときに簡単に障害となり得るすべての非常に広範囲に定義されたと記載されていない標準、中に導入されています。 ROHCの様々な部分は、ヘッダ圧縮を使用することができる周囲の環境にどのように関係するか一方が考える場合に特に場合であってもよいです。
The purpose of this document is to clarify these aspects of ROHC through examples and additional terminology, discussing terms such as ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts. This especially means to clarify how these terms relate to other terms, such as network elements and IP interfaces, which are commonly used for example when addressing MIB issues. One explicit goal of this document is to support and simplify the ROHC MIB development work.
この文書の目的は、ROHCインスタンス、ROHCチャンネル、ROHCフィードバック、およびROHCコンテキストなどの用語を検討、実施例および追加用語を通じてROHCのこれらの側面を明らかにすることです。これは、特に、これらの用語は、MIBの問題に対処する際に一般的に例示するために使用されるネットワーク要素とIPインタフェースなどの他の用語は、どのように関係するかを明らかにすることを意味します。このドキュメントのひとつ明示的な目標は、サポートとROHC MIBの開発作業を簡素化することです。
The main part of this document, sections 3 to 8, focuses on clarifying the conceptual aspects, entity relationships, and terminology of ROHC [RFC-3095]. Section 9 explains some implementation implications that arise from these conceptual aspects.
この文書の主要部分は、セクション3~8に、概念的側面、エンティティ関係、およびROHC [RFC-3095]の用語を明確に焦点を当てています。第9章では、これらの概念の側面から発生するいくつかの実装への影響を説明します。
ROHC instance
ROHCインスタンス
A logical entity that performs header compression or decompression according to one or several ROHC profiles can be referred to as a ROHC instance. A ROHC instance is either a ROHC compressor instance or a ROHC decompressor instance. See section 4.
1つまたはいくつかのROHCプロファイルに応じて、ヘッダ圧縮又は伸張を行う論理エンティティは、ROHCインスタンスと呼ぶことができます。 ROHCインスタンスは、ROHCコンプレッサインスタンスまたはROHCデコンプレッサ・インスタンスのいずれかです。セクション4を参照してください。
ROHC compressor instance
ROHCコンプレッサインスタンス
A ROHC compressor instance is a logical entity that performs header compression according to one or several ROHC profiles. There is a one-to-one relation between a ROHC compressor instance and a ROHC channel, where the ROHC compressor is located at the input end of the ROHC channel. See section 4.1.
ROHCコンプレッサインスタンスは、1つまたはいくつかのROHCプロファイルに従ってヘッダ圧縮を実行する論理エンティティです。 ROHCコンプレッサがROHCチャンネルの入力端に配置されてROHCコンプレッサインスタンスとROHCチャネルの間に一対一の関係が存在します。 4.1節を参照してください。
ROHC decompressor instance
ROHCデコンプレッサインスタンス
A ROHC decompressor instance is a logical entity that performs header decompression according to one or several ROHC profiles. There is a one-to-one relation between a ROHC decompressor instance and a ROHC channel, where the ROHC decompressor is located at the output end of the ROHC channel. See section 4.2.
ROHCデコンプレッサ・インスタンスは、1つまたはいくつかのROHCプロファイルに応じてヘッダ復元を行う論理エンティティです。 ROHCデコンプレッサは、ROHCチャネルの出力端に配置されROHCデコンプレッサインスタンスとROHCチャネルの間に一対一の関係が存在します。セクション4.2を参照してください。
Corresponding decompressor
対応するデコンプレッサ
When talking about a compressor's corresponding decompressor, this refers to the peer decompressor located at the other end of the ROHC channel to which the compressor sends compressed header packets, i.e., the decompressor that decompresses the headers compressed by the compressor.
コンプレッサーの対応するデコンプレッサについて話すとき、これは、圧縮機は、圧縮ヘッダーパケット、圧縮機で圧縮されたヘッダを解凍すなわち、減圧装置を送信先のROHCチャネルの他方の端部に位置するデコンプレッサピアを指します。
Corresponding compressor
対応するコンプレッサー
When talking about a decompressor's corresponding compressor, this refers to the peer compressor located at the other end of the ROHC channel from which the decompressor receives compressed header packets, i.e., the compressor that compresses the headers the decompressor decompresses.
デコンプレッサの対応する圧縮機について話すとき、これは減圧装置が圧縮ヘッダーパケット、デコンプレッサは、解凍ヘッダを圧縮する、すなわち、圧縮を受け、そこからROHCチャネルのもう一方の端に位置するピア・コンプレッサを指します。
ROHC peers
ROHCピア
A ROHC compressor and its corresponding ROHC decompressor are referred to as ROHC peers.
ROHC圧縮器とその対応ROHCデコンプレッサは、ROHCピアと呼ばれます。
Link
リンク
A communication path between two network entities is, in this document, generally referred to as a link.
2つのネットワークエンティティ間の通信経路は、本書では、一般に、リンクと呼ばれます。
Bi-directional compression
双方向圧縮
If there are means to send feedback information from a decompressor to its corresponding compressor, the compression performance can be improved. This way of operating, utilizing the feedback possibility for improved compression performance, is referred to as bi-directional compression.
その対応する圧縮機に解凍装置からのフィードバック情報を送信するための手段が存在する場合、圧縮性能を向上させることができます。改良された圧縮性能のフィードバックの可能性を利用し、動作のこの方法は、双方向圧縮と呼ばれています。
Unidirectional compression
単方向の圧縮
If there are no means to send feedback information from a decompressor to its corresponding compressor, the compression performance might not be as good as if feedback could be utilized. This way of operating, without making use of feedback for improved compression performance, is referred to as unidirectional compression.
それに対応する圧縮機に解凍器からのフィードバック情報を送信する手段が存在しない場合は、圧縮性能は、フィードバックを利用することができれば、ほど良くないかもしれません。改良された圧縮性能のためにフィードバックを使用することなく、動作のこの方法は、一方向圧縮と呼ばれます。
ROHC channel
ROHCチャンネル
When a ROHC compressor has transformed original packets into ROHC packets with compressed headers, these ROHC packets are sent to the corresponding decompressor through a logical point-to-point connection dedicated to that traffic. Such a logical channel, which only has to carry data in this single direction from compressor to decompressor, is referred to as a ROHC channel. See section 5.
ROHC圧縮器が圧縮ヘッダをROHCパケットに元のパケットを形質転換した場合、これらのROHCパケットがそのトラフィック専用論理ポイントツーポイント接続を介して対応する解凍器に送られます。のみ解凍器に圧縮機からのこの単一方向のデータを搬送しなければならないような論理チャネルは、ROHCチャネルと呼ばれます。セクション5を参照してください。
ROHC feedback channel
ROHCのフィードバックチャネル
To allow bi-directional compression operation, a logical point-to-point connection must be provided for feedback data from the decompressor to its corresponding compressor. Such a logical channel, which only has to carry data in the single direction from decompressor to compressor, is referred to as a ROHC feedback channel. See section 6.
双方向圧縮動作を可能にするために、論理的なポイントツーポイント接続は、対応する圧縮機に解凍器からのフィードバックデータに提供されなければなりません。唯一の圧縮機解凍器から単一方向のデータを搬送しなければならないような論理チャネルは、ROHCフィードバックチャネルと呼ばれます。セクション6を参照してください。
Co-located compressor/decompressor
同じ場所に配置コンプレッサ/デコンプレッサ
A minimal ROHC instance is only a compressor or a decompressor, communicating with a corresponding decompressor or compressor peer at the other end of a ROHC channel, thus handling packet streams sent in one direction over the link. However, in many cases, the link will carry packet streams in both directions, and it would then be desirable to also perform header compression in both directions. That would require both a ROHC compressor and a ROHC decompressor at each end of the link, each referred to as a co-located compressor/decompressor pair.
最小のROHCのインスタンスは、このようにリンクを介して一方向に送信されたパケットストリームを処理する、ROHCチャネルの他方の端部に対応する逆圧縮器又は圧縮機ピアと通信するだけ圧縮または解凍器です。しかし、多くの場合、リンクが双方向にパケットストリームを運ぶ、その後も両方向にヘッダ圧縮を行うことが望ましいであろう。すなわち、それぞれが同一位置のコンプレッサ/デコンプレッサのペアと呼ばれる、ROHC圧縮器及びリンクの各端にROHCデコンプレッサとの両方を必要とするであろう。
Associated compressor/decompressor
関連する圧縮/伸張
If there is a co-located ROHC compressor/decompressor pair at each end of a link, feedback messages can be transmitted from a ROHC decompressor to its corresponding compressor by creating a virtual ROHC feedback channel among the compressed header packets sent from the co-located ROHC compressor to the decompressor co-located with the compressor at the other end. When a co-located ROHC compressor/decompressor pair is connected for this purpose, they are said to be associated with each other.
同じ場所に配置ROHC圧縮器/伸張器のペアは、リンクの各端部にある場合、フィードバックメッセージは、共位置から送信された圧縮ヘッダーパケットのうち、仮想ROHCフィードバックチャネルを作成することにより、ROHCデコンプレッサからその対応する圧縮機に伝達することができますデコンプレッサへROHC圧縮器は、もう一方の端に圧縮機と同じ場所に配置します。同じ場所に配置ROHC圧縮器/伸張器のペアは、この目的のために接続されている場合、それらは相互に関連していると言われています。
Interspersed feedback
散在フィードバック
Feedback from a ROHC decompressor to a ROHC compressor can either be sent on a separate ROHC feedback channel dedicated to feedback packets, or sent among compressed header packets going in the opposite direction from a co-located (associated) compressor to a similarly co-located decompressor at the other end of the link. If feedback packets are transmitted in the latter way and sent as stand-alone packets, this is referred to as interspersed feedback. See section 6.2 for an example.
ROHC圧縮器にROHCデコンプレッサからのフィードバックは、いずれかのフィードバックパケットに専用の別個のROHCフィードバックチャネル上で送信され、または同じ場所に配置（関連）、圧縮機から同様に同一位置と反対方向に向かう圧縮ヘッダーパケットのうち送信することができますリンクのもう一方の端の解凍器。フィードバックパケットが後者の方法で送信され、スタンドアロンパケットとして送信される場合、これは散在フィードバックと呼ばれます。例えばセクション6.2を参照してください。
Piggybacked feedback
ピギーバックフィードバック
Feedback from a ROHC decompressor to a ROHC compressor can either be sent on a separate ROHC feedback channel dedicated to feedback packets, or sent among compressed header packets going in the opposite direction from a co-located (associated) compressor to a similarly co-located decompressor at the other end of the link. If feedback packets are transmitted in the latter way and sent encapsulated within compressed header packets going in the other direction, this is referred to as piggybacked feedback. See section 6.2 for an example.
ROHC圧縮器にROHCデコンプレッサからのフィードバックは、いずれかのフィードバックパケットに専用の別個のROHCフィードバックチャネル上で送信され、または同じ場所に配置（関連）、圧縮機から同様に同一位置と反対方向に向かう圧縮ヘッダーパケットのうち送信することができますリンクのもう一方の端の解凍器。フィードバックパケットが後者の方法で送信され、他の方向に向かう圧縮ヘッダーパケット内にカプセル化され送信された場合、これは、ピギーバックフィードバックと呼ばれます。例えばセクション6.2を参照してください。
Dedicated feedback channel
専用のフィードバックチャネル
A dedicated feedback channel is a logical layer two channel from a ROHC decompressor to a ROHC compressor, used only to transmit feedback packets. See sections 6.1 and 6.3 for examples.
専用のフィードバックチャネルのみフィードバックパケットを送信するために使用されるROHC圧縮器にROHCデコンプレッサから論理層2チャンネルです。セクションに例については、6.1と6.3を参照してください。
When considering aspects of ROHC that relate to the surrounding networking environment where header compression may be applied, unnecessary confusion is easily created because a common, well understood, and well defined, terminology is missing. One major goal with this document is to define the preferred terminology to use when discussing header compression network integration issues.
ヘッダ圧縮を適用することができる一般的なものは、よく理解され、明確に定義されているため、不要な混乱が容易に作成され、周囲のネットワーク環境に関するROHCの側面を考慮するとき、用語がありません。この文書の一つの主要な目標は、ヘッダ圧縮ネットワーク統合の問題を議論する際に使用する優先用語を定義することです。
Header compression is applied over certain links, between two communicating entities in a network. Such entities may be referred to as "nodes", "network devices", or "network elements", all terms usually having the same meaning. However, practice within the area of network management favors using the term "network element", which is therefore consistently used throughout the rest of this document.
ヘッダ圧縮は、ネットワーク内の2つの通信エンティティ間で、特定のリンク上で適用されます。そのようなエンティティは、「ノード」、「ネットワークデバイス」、または「ネットワーク要素」、すべての用語は、通常、同一の意味を有すると呼ぶことができます。しかし、そのため常にこのドキュメントの残りの部分全体で使用される用語「ネットワークエレメント」を使用して、ネットワーク管理の好意の領域内で練習します。
A network element communicates through one or several network interfaces, which are often subject to network management, as defined by MIB specifications. In all IP internetworking, each such interface has its own IP identity, providing a common network interface abstraction, independent of the link technology hidden below the interface. Throughout the rest of this document, such interfaces will be referred to as "IP interfaces".
ネットワーク要素は、MIB仕様によって定義されるように、多くの場合、ネットワーク管理の対象である1つのまたは複数のネットワークインタフェースを介して通信します。すべてのIPインターネットワーキングでは、それぞれ、このようなインターフェイスは、インターフェイスの下に隠されたリンク技術に依存しない共通のネットワークインタフェースの抽象化を提供する、独自のIPの同一性を有します。この文書の残りの部分を通して、そのようなインターフェイスは、「IPインターフェース」と呼ぶことにします。
Thus, to visualize the above terms, the top level hierarchy of a network element is as follows, with one or several IP interfaces:
従って、上記の用語を可視化するために、1つのまたは複数のIPインターフェイスと、次のように、ネットワーク要素の最上位階層です。
+-----------------------------------------------------+
| Network Element |
+---------------+--+---------------+------------------+
| IP | | IP |
| Interface | | Interface |
+---------------+ +---------------+ ...
The next section builds on this top level hierarchy by looking at what is below an IP interface.
次のセクションでは、IPインタフェースの下にあるものを見ることで、このトップレベルの階層に基づいています。
As mentioned in the previous section, an IP interface can be implemented on top of almost any link technology, although different link technologies have different characteristics, and provide communication by different means. However, all link technologies provide the common capability to send and/or receive data to/from the IP interface. A generic way of visualizing the common ability to communicate is to envision it as one or several logical communication channels provided by the link, where each channel can be either bi-directional or unidirectional. Such logical point-to-point connections will, throughout the rest of this document, be referred to as "channels", either bi-directional or unidirectional. Note that this definition of "channels" is less restrictive than the definition of "ROHC channels", as given in section 5.
前節で述べたように、IPインタフェースは、異なるリンク・テクノロジーが異なる特性を有しているが、ほとんどすべてのリンク・テクノロジーの上に実装し、異なる手段によって通信を提供することができます。しかし、すべてのリンク技術は、IPインタフェースから/にデータを送信および/または受信するための共通機能を提供します。通信するための共通の能力を視覚化する一般的な方法は、各チャネルは、双方向または単方向のどちらかであることができるリンクによって提供される一つまたは複数の論理通信チャネルとして、それを想像することです。このような論理的なポイントツーポイント接続は、この文書の残りの部分で、双方向または単方向のどちらか、「チャンネル」、と呼ぶことにします。セクション5に示すように「チャネル」のこの定義は、「ROHCチャンネル」の定義よりも少ない制限であることに留意されたいです。
Extending the above network element hierarchy with the concept of channels would then lead to the following:
次につながるチャネルの概念を上記ネットワーク要素の階層の拡張：
+-----------------------------------------------------+
| Network Element |
+---------------+--+---------------+------------------+
| IP | | IP |
| Interface | | Interface |
++ +-+ +-+ +----+ ++ +-+ +-+ +----+ ...
|C| |C| |C| |C| |C| |C|
|h| |h| |h| |h| |h| |h|
|a| |a| |a| |a| |a| |a|
|n| |n| |n| ... |n| |n| |n| ...
|n| |n| |n| |n| |n| |n|
|e| |e| |e| |e| |e| |e|
|l| |l| |l| |l| |l| |l|
: : : : : : : : : : : :
Whether there is more than one channel, and whether the channel(s) is/are bi-directional or unidirectional (or a mix of both) is link technology dependent, as is the way in which channels are logically created.
チャンネルが論理的に作成される方法であるとしてそこかどうかは、リンク・テクノロジーに依存している複数のチャネルであり、チャネル（複数可）があるかどうか/双方向または単方向（あるいはその両方のミックス）です。
The following subsections, 3.3-3.6, give a number of different link examples, and relate these to the general descriptions above. Further, each section discusses how header compression might be applied in that particular case. The core questions for header compression are:
以下のサブセクションでは、3.3から3.6までは、異なるリンクの例の数を与え、上記一般的な説明にこれらを関連付けます。さらに、各セクションは、ヘッダ圧縮は、その特定の場合に適用されるかもしれない方法について説明します。ヘッダ圧縮のためのコアの質問は以下のとおりです。
- Are channels bi- or unidirectional? - Is the link point-to-point? If not, a lower layer addressing scheme is needed to create logical point-to-point channels.
- チャンネル二または単方向性はありますか？ - リンクポイントツーポイントのですか？ない場合は、下位層アドレス方式は、論理的なポイントツーポイントのチャネルを作成するために必要とされます。
Note that these subsections talk about header compression in general, while later sections will address the case of ROHC in more detail. Further, one should remember that in the later sections, the general channel definition is slightly enhanced for header compression by the definition of the ROHC channel (section 5) and the ROHC feedback channel (section 6), while here the basic channel concept is used, as defined above.
以降のセクションでは、より詳細にROHCの場合に対処する一方、これらのサブセクションでは、一般のヘッダ圧縮について話すことに留意されたいです。さらに、人はここで、基本的なチャネルの概念を用いているが、後のセクションで、一般的なチャネル定義はわずかに、ROHCチャンネル（セクション5）の定義とROHCフィードバックチャネル（セクション6）によりヘッダ圧縮のために強化されることを覚えておいてください、上記のように定義されます。
The simplest possible link example one can derive from the general overview above is the case with one single unidirectional channel between two communicating network elements.
一方が上記一般的な概要から導出することができる最も簡単なリンクの例では、2つの通信ネットワーク要素との間に1つの単方向チャネルの場合です。
+-----------------+ +-----------------+
| Network Element | | Network Element |
+-----------------+ +-----------------+
| IP | | IP |
| Interface | | Interface |
+------+ +------+ +------+ +------+
| | | |
| +--------------------------------+ |
| -> Unidirectional channel -> |
+----------------------------------------+
A typical example of a point-to-point link with one unidirectional channel like this is a satellite link. Since there is no return path present, only unidirectional header compression can be applied here.
このようなもの一方向チャネルとのポイントツーポイントリンクの典型的な例は、衛星リンクです。ノーリターンパスが存在しないので、一方向のみヘッダ圧縮は、ここで適用することができます。
Taking the above example one step further, the natural extension would be an example with one single bi-directional channel between two communicating network elements. In this example, there are still only two endpoints and one single channel, but the channel is simply enhanced to allow bi-directional communication.
さらに一歩上の例を取って、自然な拡張は、2つの通信ネットワーク要素との間に1つの双方向チャネルを有する例であろう。この例では、まだそこにのみ、2つのエンドポイントと、一つのチャンネルであるが、チャネルは、単に双方向通信を可能にするために強化されます。
+-----------------+ +-----------------+
| Network Element | | Network Element |
+-----------------+ +-----------------+
| IP | | IP |
| Interface | | Interface |
+------+ +------+ +------+ +------+
| | | |
| +--------------------------------+ |
| <-> Bi-directional channel <-> |
+----------------------------------------+
A typical example of a point-to-point link with such a bi-directional channel is a PPP modem connection over a regular telephone line. Header compression can easily be applied here as well, as is usually done over e.g., PPP, and the compression scheme can make use of the return path to improve compression performance.
そのような双方向チャネルとのポイントツーポイントリンクの典型的な例は、通常の電話回線を介してPPPモデム接続です。通常、例えば、PPPを介して行われているようにヘッダ圧縮を容易に、ここでも同様に適用することができ、圧縮方式は、圧縮性能を向上させるためにリターンパスを利用することができます。
Leaving the simple point-to-point link examples, this section addresses the case of a bi-directional link connecting more than two communicating network elements. To simplify the example, the case with three endpoints is considered.
単純なポイントツーポイントリンクの例を残し、このセクションでは、二つ以上の通信ネットワーク要素を接続する双方向リンクの場合に対処します。例を単純化するために、3つのエンドポイントを持つ場合を考えます。
+-----------------+ +-----------------+ +-----------------+
| Network Element | | Network Element | | Network Element |
+-----------------+ +-----------------+ +-----------------+
| IP | | IP | | IP |
| Interface | | Interface | | Interface |
+------+ +------+ +------+ +------+ +------+ +------+
| | | | | |
| | | | | |
| +-----------------+ +-----------------+ |
| <-> Bi-directional "shared channel" <-> |
+-----------------------------------------------+
A typical example of a multipoint link with such a bi-directional "shared channel" is an Ethernet. Since the channel is shared, applying header compression would require a lower layer addressing scheme to provide logical point-to-point channels, according to the definition of "channels".
このような双方向の「共有チャネル」とマルチポイントリンクの典型的な例は、イーサネット（登録商標）です。チャネルが共有されるため、ヘッダ圧縮を適用して「チャネル」の定義によれば、論理ポイントツーポイントチャネルを提供するために下位レイヤアドレッシングスキームを必要とするであろう。
As an aside, it should be noted that a case of unidirectional multipoint links is basically the same as a number of unidirectional point-to-point links. In such a case, each receiver only sees one single sender, and the sender's behavior is independent of the number of receivers and is unaffected by their behavior.
余談として、一方向マルチポイントリンクの場合は、基本的に単方向ポイントツーポイントリンクの数と同じであることに留意すべきです。そのような場合には、各受信機は、ただ1つの送信者を見て、送信者の行動は、受信機の数とは無関係であり、彼らの行動に影響されません。
This final example addresses a scenario which is expected to be typical in many environments where ROHC will be applied. The key point of the example is the multi-channel property, which is common in, for example, cellular environments. Data through the same IP interface might here be transmitted on different channels, depending on its characteristics. In the following example, there are three channels present, one bi-directional, and one unidirectional in each direction, but the channel configuration could of course be arbitrary.
この最後の例では、ROHCが適用される多くの環境において典型的であると予想されるシナリオに対処します。実施例の重要な点は、例えば、セルラ環境で一般的なマルチチャネル性、です。同じIPインタフェースを介したデータは、ここではその特性に応じて、異なるチャネル上で送信される可能性があります。以下の例では、3つのチャネルは、一双方向、各方向に1つの一方向が、チャネル構成はもちろん任意であってもよい、存在しています。
+-----------------+ +-----------------+
| Network Element | | Network Element |
+-----------------+ +-----------------+
| IP | | IP |
| Interface | | Interface |
+-+ +---+ +---+ +-+ +-+ +---+ +---+ +-+
| | | | | | | | | | | |
| | | | | +--------------------------+ | | | | |
| | | | | <- Unidirectional channel <- | | | | |
| | | | +------------------------------+ | | | |
| | | | | | | |
| | | | | | | |
| | | +--------------------------------------+ | | |
| | | <-> Bi-directional channel <-> | | |
| | +------------------------------------------+ | |
| | | |
| | | |
| +--------------------------------------------------+ |
| -> Unidirectional channel -> |
+------------------------------------------------------+
As mentioned above, a typical example of a multi-channel link is a cellular wireless link. In this example, header compression would be applicable on a per-channel basis, for each channel operating either in a bi-directional or unidirectional manner, depending on the channel properties.
上述したように、マルチチャンネルリンクの典型的な例は、セルラー無線リンクです。この例では、ヘッダ圧縮チャネル特性に応じて双方向または単方向の方法のいずれかで動作する各チャネルのために、チャネルごとに適用可能であろう。
For various purposes, such as network management on an IP interface implementing ROHC, it is necessary to identify the various ROHC entities that might be present on an interface. Such a minimal ROHC entity will, from now on, be referred to as a "ROHC instance". A ROHC instance can be one of two different types, either a "ROHC compressor" or a "ROHC decompressor" instance, and an IP interface can have N ROHC compressors and M ROHC decompressors, where N and M are arbitrary numbers. It should be noted that although a compressor is often co-located with a decompressor, a ROHC instance can never include both a compressor and a decompressor; where both are present, they will be referred to as two ROHC instances.
そのようなROHCを実装するIPインタフェース上のネットワーク管理など、様々な目的のために、インターフェイス上に存在する可能性のある様々なROHCエンティティを識別する必要があります。そのような最小のROHCエンティティは、今から、「ROHCインスタンス」と呼ぶことにします。 ROHCインスタンスは、N及びMは任意の数である二つの異なるタイプの一つ、「ROHC圧縮器」または「ROHCデコンプレッサ」インスタンス、及びN ROHCコンプレッサ及びMのROHCデコンプレッサを有することができ、IPインタフェースのいずれかとすることができます。 ROHCインスタンスは圧縮と減圧の両方を含むことはできません、圧縮機はしばしば減圧装置と同じ場所に配置されているがことに留意すべきです。両方が存在する場合、それらは、二つのROHCインスタンスと呼ぶことにします。
The following two subsections describe the two kinds of ROHC instances and their external interfaces, while sections 5 and 6 address how communication over these interfaces is realized through "ROHC channels" and "ROHC feedback channels". Section 7 builds on top of the instance, channel and feedback channel concepts, and clarifies how ROHC contexts map to this.
次の2つのサブセクションは、ROHCインスタンスとその外部インターフェイスの二種類、これらのインタフェースを介した通信は、「ROHCチャンネル」および「ROHCフィードバックチャネル」を介して実現されている方法を、一方のセクション5及び6のアドレスが記載されています。第7節は、例えば、チャネルおよびフィードバックチャネルの概念の上に構築され、ROHCコンテキストはこれにマッピングする方法を明確にしています。
It should be noted that all figures in sections 4-6 have been rotated 90 degrees to simplify drawing, i.e., they do not show a "stack view".
セクション4-6のすべての数字はつまり、彼らは「スタックビュー」を表示しない、図面を簡単にするために90度回転されていることに留意すべきです。
A ROHC compressor instance supports header compression according to one or several ROHC profiles. Apart from potential configuration or control interfaces, a compressor instance receives and sends data through 3 inputs and 1 output, as illustrated by the figure below:
ROHCコンプレッサインスタンスは、1つまたはいくつかのROHCプロファイルに従ってヘッダ圧縮をサポートします。別に電位設定または制御インターフェースから、コンプレッサインスタンスを受信し、以下の図で示すように、3入力1つの出力を介してデータを送信します。
+--------------+
-> UI -> | | -> CO ->
| ROHC |
| Compressor |
-> PI -> | | <- FI <-
+--------------+
Uncompressed Input (UI): Uncompressed packets are delivered from higher layers to the compressor through the UI.
非圧縮入力（UI）：圧縮されていないパケットは、UIを介して圧縮機に上位層から送達されます。
Compressed Output (CO): Compressed packets are sent from the compressor through the CO, which is always connected to the input end of a ROHC channel (see section 5).
圧縮された出力（CO）：圧縮されたパケットは、常にROHCチャンネルの入力端に接続されているCOを介して圧縮機から送信された（セクション5を参照）。
Feedback Input (FI): Feedback from the corresponding [optional] decompressor is received by the compressor through the FI, which (if present) is connected to the output end of a ROHC feedback channel of some kind (see section 6). When there are no means to transmit feedback from decompressor to compressor, FI is not used, and bi-directional compression will not be possible.
フィードバック入力（FI）：対応する[オプション]解凍器からのフィードバックは、（存在する場合）、ある種のROHCフィードバックチャネルの出力端に接続されているFIを介して圧縮機によって受信される（セクション6を参照）。解凍器から圧縮機にフィードバックを送信する手段が存在しない場合、FIは使用されず、双方向圧縮は可能ではないであろう。
Piggyback Input (PI): If the compressor is associated with a [optional] co-located decompressor, for which the compressor delivers feedback to the other end of the link, feedback data for piggybacking is delivered to the compressor through the PI. If this input is used, it is connected to the FO of the co-located decompressor (see section 4.2).
入力（PI）をピギーバック圧縮機は、圧縮機は、リンクのもう一方の端にフィードバックを配信するための[オプション]コロケート減圧装置、関連付けられている場合、ピギーバックのためのフィードバックデータは、PIを介して圧縮機に供給されます。この入力が使用される場合、それは同じ場所に配置デコンプレッサのFO（セクション4.2を参照）に接続されています。
A ROHC decompressor instance supports header decompression according to one or several ROHC profiles. Apart from potential configuration or control interfaces, a decompressor instance receives and sends data through 1 input and 3 outputs, as illustrated by the figure below:
ROHCデコンプレッサ・インスタンスは、1つまたはいくつかのROHCプロファイルに従ってヘッダ復元をサポートします。別に電位設定または制御インターフェースから、デコンプレッサインスタンスが受信して、下図で示されるように、1入力3つの出力を介してデータを送信します。
+--------------+
-> CI -> | | -> DO ->
| ROHC |
| Decompressor |
<- FO <- | | -> PO ->
+--------------+
Compressed Input (CI): Compressed packets are received by the decompressor through the CI, which is always connected to the output end of a ROHC channel (see section 5).
圧縮された入力（CI）：圧縮されたパケットは、常にROHCチャネルの出力端に接続されているCIを介して減圧装置によって受信される（セクション5を参照）。
Decompressed Output (DO): Decompressed packets are delivered from the decompressor to higher layers through the DO.
減圧出力（DO）：解凍パケットがDOを介して上位層に減圧装置から送達されます。
Feedback Output (FO): Feedback to the corresponding compressor [optional] is sent from the compressor through the FO, which (if present) is connected to the input end of a ROHC feedback channel of some kind (see section 6). When there are no means to transmit feedback from decompressor to compressor, FO is not used, and bi-directional compression will not be possible.
フィードバック出力（FO）：対応する圧縮機へのフィードバックは、[オプション]（存在する場合）、ある種のROHCフィードバックチャネルの入力端に接続されてFOを介して圧縮機から送信される（セクション6を参照）。解凍器から圧縮機にフィードバックを送信する手段が存在しない場合、FOは使用されず、双方向圧縮は可能ではないであろう。
Piggyback Output (PO): If the decompressor is associated with [optional] a co-located compressor to which the decompressor delivers feedback it receives piggybacked from the other end of the link, the received feedback data is delivered from the decompressor through the PO. If this output is used, it is connected to the FI of the co-located compressor (see section 4.1).
出力（PO）をピギーバック：解凍装置は圧縮解除装置は、それがリンクの他端からピギーバック、受信されたフィードバックデータはPOを介して減圧装置から配信された受信フィードバックを提供して[オプション]同一位置コンプレッサに関連付けられている場合。この出力が使用される場合、それは同じ場所に配置コンプレッサのFIに接続されている（セクション4.1を参照）。
In section 3, a general concept of channels was introduced. According to that definition, a channel is basically a logical point-to-point connection between the IP interfaces of two communicating network elements. By that definition, a channel represents the kind of logical connection needed to make header compression generally applicable, and then the channel properties control whether compression can operate in a unidirectional or bi-directional manner.
セクション3では、チャンネルの一般的な概念が導入されました。その定義によれば、チャンネルは基本的に2つの通信ネットワーク要素のIPインターフェイス間の論理的なポイントツーポイント接続です。その定義により、チャネルがヘッダ圧縮は、一般的に適用するために必要な論理接続の種類を表し、そして、チャネル特性は、圧縮が一方向または双方向の様式で動作することができるかどうかを制御します。
The channel concept thus facilitates general header compression discussions, but since it groups unidirectional and bi-directional connections together, it does not provide the means for describing details of how ROHC logically works. Therefore, for the case of ROHC, the channel concept is enhanced and a more restricted concept of "ROHC channels" is defined.
チャネルの概念は、このように一般的なヘッダ圧縮の議論を容易にするが、一緒にグループ一方向と双方向接続ので、ROHCは、論理的にどのように機能するかの詳細を説明するための手段を提供しません。したがって、ROHCの場合のために、チャネル概念が強調され、「ROHCチャンネル」のより制限された概念が定義されます。
A ROHC channel has the same properties as a channel, with the difference that a ROHC channel is always unidirectional. A ROHC channel therefore has one single input endpoint, connected to the CO of one single ROHC compressor instance, and one single output endpoint, connected to the CI of one single ROHC decompressor instance. A ROHC channel must thus in this way be logically dedicated to one ROHC compressor and one ROHC decompressor, hereafter referred to as ROHC peers, creating a one-to-one mapping between a ROHC channel and two ROHC compressor/decompressor peers.
ROHCチャンネルはROHCチャネルは常に一方向であるという点は相違させて、チャネルと同じ特性を有します。 ROHCチャンネルは、従って、単一のROHCコンプレッサインスタンスのCOに接続された1つの単一の入力エンドポイント、および1つのROHCデコンプレッサインスタンスのCIに接続された1つの単一の出力エンドポイントを有します。 ROHCチャネルは、したがって、このように論理的にROHCチャンネル二ROHCコンプレッサ/デコンプレッサピアとの間の1対1のマッピングを作成し、以下ROHCピアと呼ばれる1つのROHC圧縮器と一つROHCデコンプレッサに捧げなければなりません。
+--------------+ --->-->-->-->--- +--------------+
| | -> CO -> ROHC Channel -> CI -> | |
| ROHC | --->-->-->-->--- | ROHC |
| Compressor | | Decompressor |
| | | |
+--------------+ +--------------+
In many cases the lower layer channel is by nature bi-directional, but for ROHC communication over that channel, a ROHC channel would only represent one communication direction of that channel. For bi-directional channels, a common case would be to logically allocate one ROHC channel in each direction, allowing ROHC compression to be performed in both directions. The reason for defining ROHC channels as unidirectional is basically to separate and generalize the concept of feedback, as described and exemplified in section 6.
多くの場合、下位層チャネルは、双方向の性質によるものであるが、そのチャネル上ROHCの通信のために、ROHCチャンネルのみそのチャネルの通信方向を表すことになります。双方向チャネルに対して、共通の場合は、論理的にROHC圧縮が両方向で行うことを可能にする、各方向の一方ROHCチャネルを割り当てることであろう。一方向としてROHCチャネルを定義する理由は、セクション6に記載され、例示されるように、フィードバックの概念を分離し、一般化する基本的です。
Since ROHC can be implemented over various kinds of links, unidirectional or bi-directional one-channel links, as well as multi-channel links, the logical transmission of feedback from decompressor to compressor has been separated out from the transport of actual ROHC packets through the definition of ROHC channels as always being unidirectional from compressor to decompressor. This means that an additional channel concept must be defined for feedback, which is what will hereafter be referred to as "ROHC feedback channels".
ROHCは、リンク、一方向又は双方向1チャンネルリンク、ならびにマルチチャネルリンクの各種の上に実装することができるので、圧縮機の解凍装置からのフィードバックの論理的な伝送を介して実際のROHCパケットのトランスポートから分離されました常にコンプレッサから解凍装置への一方向のものとしてROHCチャンネルの定義。これは、追加チャネルのコンセプトは、以下「ROHCのフィードバックチャネル」と呼ばれるものをしている、フィードバックのために定義されなければならないことを意味しています。
In the same way as a ROHC channel is a logically dedicated unidirectional channel from a ROHC compressor to its corresponding ROHC peer decompressor, a ROHC feedback channel is a logically dedicated unidirectional channel from a ROHC decompressor to its corresponding ROHC peer compressor. A ROHC feedback channel thus has one single input endpoint, connected to the FO of one single ROHC decompressor instance, and one single output endpoint, connected to the FI of one single ROHC compressor instance.
ROHCチャネルと同様に、ROHC圧縮器からその対応ROHCピアデコンプレッサと論理的専用単方向チャネルである、ROHCフィードバックチャネルは、その対応するROHCピア圧縮機にROHCデコンプレッサから論理的に個別の単方向チャネルです。 ROHCフィードバックチャネルは、このように一つのROHCデコンプレッサインスタンスのFOに接続された1つの単一の入力エンドポイント、および1つのROHCコンプレッサインスタンスのFIに接続された1つの単一の出力エンドポイントを有します。
+--------------+ +--------------+
| | | |
| ROHC | | ROHC |
| Compressor | --<--<--<--<--<-- | Decompressor |
| | <- FI <- ROHC FB Channel <- FO <- | |
+--------------+ --<--<--<--<--<-- +--------------+
The reason for making this simplification and logically separating ROHC channels from ROHC feedback channels is generality for handling of feedback. ROHC has been designed with the assumption of logical separation, which creates flexibility in realizing feedback transport, as discussed in [RFC-3095, section 5.2.1]. There are no restrictions on how to implement a ROHC feedback channel, other than that it must be made available and be logically dedicated to the ROHC peers if bi-directional compression operation is to be allowed.
この単純化を行うと、論理的にROHCフィードバックチャネルからROHCチャンネルを分離する理由は、フィードバックの取り扱いのための一般性です。 [RFC-3095、セクション5.2.1]で説明したようにROHCは、フィードバック転送を実現する上での柔軟性を作成する論理的な分離の前提で設計されています。それが利用できるようにする必要があり、双方向の圧縮動作が許可される場合、論理的にROHCピアに専念すること以外のROHCのフィードバックチャネルを、実装方法に制限はありません。
The following subsections provide some, not at all exhaustive, examples of how a ROHC feedback channel might possibly be realized.
以下のサブセクションでは、いくつか、全然網羅、ROHCフィードバックチャネルは、おそらく実現されるかもしれない方法の例を示します。
This section illustrates a one-way compression example where one bi-directional channel has been configured to represent a ROHC channel in one direction and a dedicated ROHC feedback channel in the other direction.
このセクションでは、一つの双方向チャネルが一方向および他方向に専用ROHCフィードバックチャネルにおいてROHCチャンネルを表すように構成された一方向の圧縮の一例を示す図です。
Bi-directional channel
..................
+--------------+ : -->-->-->-->-- : +--------------+
--> |UI CO| --> : ROHC Channel : --> |CI DO| -->
| ROHC | : -->-->-->-->-- : | ROHC |
| Compressor | : : | Decompressor |
| | : --<--<--<--<-- : | |
o |PI FI| <-- : FB Channel : <-- |FO PO| o
+--------------+ : --<--<--<--<-- : +--------------+
:................:
In this example, feedback is sent on its own dedicated channel, as discussed in e.g., feedback realization example 1-3 of ROHC [RFC-3095, page 44]. This means that the piggybacking/interspersing mechanism of ROHC is not used, and the PI/PO connections are thus left open (marked with a "o"). To facilitate communication with ROHC compression in a two-way manner using this approach, an identical configuration must be provided for the other direction, i.e., making use of four logical unidirectional channels.
例えば、ROHCのフィードバックの実現例1-3 [RFC-3095、ページ44]で説明したように、この例では、フィードバックは、それ自身の専用チャネル上で送信されます。これは、ROHCのピギーバッキング/散在メカニズムが使用されていない、とPI / POの接続は、このように（「O」でマークされた）開いたままになっていることを意味します。このアプローチを使用して双方向的にROHC圧縮との通信を容易にするため、同一の構成には、4つの論理一方向チャネルを利用すること、すなわち、他の方向のために提供されなければなりません。
This section illustrates how a bi-directional channel has been configured to represent one ROHC channel in each direction, while still allowing feedback to be transmitted through ROHC piggybacking and interspersing.
このセクションでは、双方向チャネルが依然としてフィードバックがROHCの便乗と散在を介して送信されることを可能にしながら、各方向に1つのROHCチャンネルを表すように構成されている様子を示します。
Bi-directional channel
..................
+--------------+ : -->-->-->-->-- : +--------------+
--> |UI CO| --> : ROHC Channel A : --> |CI DO| -->
| ROHC | : -->-->-->-->-- : | ROHC |
| Compressor | : : | Decompressor |
| A | : : | A |
+-> |PI FI| <-+ : : +-- |PO FO| --+
| +--------------+ | : : | +--------------+ |
| | : : | |
| | : : | |
| +--------------+ | : : | +--------------+ |
+-- |FO PO| --+ : : +-> |FI PI| <-+
| ROHC | : : | ROHC |
| Decompressor | : : | Compressor |
| B | : --<--<--<--<-- : | B |
<-- |DO CI| <-- : ROHC Channel B : <-- |CO UI| <--
+--------------+ : --<--<--<--<-- : +--------------+
:................:
In this example, feedback is transmitted piggybacked or interspersed among compressed header packets in the ROHC channels, as discussed in e.g., feedback realization example 4-6 of ROHC [RFC-3095, page 44]. Feedback from decompressor A to compressor A is here sent through FO(A)->PI(B), piggybacked on a compressed packet over ROHC channel B, and delivered to compressor A through PO(B)->FI(A). A logical ROHC feedback channel is thus provided from the PI input at compressor B to the PO output at decompressor B. It should be noted that in this picture, PO and FO at the decompressors have been swapped to simplify drawing.
例えば、ROHC [RFC-3095、ページ44]のフィードバックの実現例4-6で説明したように、この例では、フィードバックは、ピギーバックまたはROHCチャネル内の圧縮ヘッダーパケットの間に散在送信されます。 Aを圧縮機にデコンプレッサからのフィードバックをここでFO（A）を介して送信される - > PI（B）、ROHCチャネルB上に圧縮されたパケットにピギーバック、及びPO（B）を介して圧縮機に供給 - > FI（A）。論理ROHCフィードバックチャネルは、したがって、この画像に、POおよびFOは解凍器で図面を簡略化するために交換されていることに留意すべきである減圧装置BでPO出力する圧縮機BにおけるPI入力から提供されます。
This section illustrates how two bi-directional channels have been configured to represent two ROHC channels and two dedicated ROHC feedback channels, respectively.
このセクションでは、2つの双方向チャネルは、それぞれ、2つのROHCチャネルと2つの専用ROHCフィードバックチャネルを表すように構成されている様子を示します。
Bi-directional channel
..................
+--------------+ : -->-->-->-->-- : +--------------+
->|UI CO| --> : ROHC Channel A : --> |CI DO|->
| ROHC | : -->-->-->-->-- : | ROHC |
| Compressor | : : | Decompressor |
| A | : : | A |
| | : : | |
+-> |FI PI| o : : o |PO FO| --+
| +--------------+ : --<--<--<--<-- : +--------------+ |
| +- : ROHC Channel B :<-+ |
| | : --<--<--<--<-- : | |
| +--------------+ | :................: | +--------------+ |
| <-|DO CI|<-+ +- |CO UI|<- |
| | ROHC | | ROHC | |
| | Decompressor | Bi-directional channel | Compressor | |
| | B | .................. | B | |
| | | : -->-->-->-->-- : | | |
| o|PO FO| --> : FB Channel B : --> |FI PI|o |
| +--------------+ : -->-->-->-->-- : +--------------+ |
| : : |
| : --<--<--<--<-- : |
+----------------------- : FB Channel A : <----------------------+
: --<--<--<--<-- :
:................:
In this example, feedback is, in both directions, sent on its own dedicated channel, as discussed in e.g., feedback realization example 1-3 of ROHC [RFC-3095, page 44]. With this configuration, the piggybacking/interspersing mechanism of ROHC is not used, and the PI/PO connections are thus left open (marked with a "o"). It should be noted that in this picture FI/PI and PO/FO at the A-instances have been swapped to simplify drawing, while the B-instances have been horizontally mirrored.
この例では、フィードバックは、例えば、ROHCのフィードバックの実現例1-3 [RFC-3095、ページ44]で議論するように、それ自身の専用チャネル上で送信される、両方向です。この構成では、ROHCのメカニズムを散在ピギーバッキングは/使用されず、PI / POの接続は、このように（「O」でマークされた）を開放しています。 B-インスタンスが水平にミラーされているが、この画像FI / PI及びPO / FOのA-インスタンスで、図面を簡略化するために交換されていることに留意すべきです。
In previous sections, it has been clarified that one network element may have multiple IP interfaces, one IP interface may have multiple ROHC instances running (not necessarily both compressors and decompressors), and for each ROHC instance, there is exactly one ROHC channel and optionally one ROHC feedback channel. How ROHC channels and ROHC feedback channels are realized will differ from case to case, depending on the actual layer two technology used.
前のセクションでは、1つのネットワーク要素は、単一のIPインターフェースが複数ROHCインスタンスが（必ずしも圧縮及び解凍器の両方）を実行する必要がある可能性があり、複数のIPインターフェースを有し、各ROHCインスタンスに対して、必要に応じて正確に一つのROHCチャネルとが存在することが明らかにされています1つのROHCフィードバックチャネル。 ROHCチャンネル、ROHCのフィードバックチャネルが実現されているどのように使用される実際の層2技術に応じて、ケースにケースとは異なります。
Each compressor/decompressor can further compress/decompress an arbitrary (but limited) number of concurrent packet streams sent over the ROHC channel connected to that compressor/decompressor. Each packet stream relates to one particular context in the compressor/decompressor. When sent over the ROHC channel, compressed packets are labeled with a context identifier (CID), indicating to which context the compressed packet corresponds. There is thus a one-to-one mapping between the number of contexts that can be present in a compressor/decompressor and the context identifier (CID) space used in compressed packets over that ROHC channel. This is illustrated by the following figure:
各コンプレッサ/デコンプレッサはさらに、コンプレッサ/デコンプレッサに接続されたROHCチャネルを介して送信された同時パケットストリームの任意の（しかし限定）数を解凍/圧縮することができます。各パケットストリームは、圧縮/伸張器内の1つの特定のコンテキストに関する。 ROHCチャネルを介して送信される場合、圧縮されたパケットは、圧縮されたパケットは、対応するコンテキストを示す、コンテキスト識別子（CID）で標識されます。コンプレッサ/デコンプレッサとそのROHCチャネル上で圧縮されたパケットで使用されるコンテキスト識別子（CID）空間内に存在することができるコンテキストの数との間の1対1のマッピングが存在します。これは、次の図で示されています：
+------------------------------------------------------------------+
| IP Interface |
+---------------+----+---------------+----+---------------+--------+
| ROHC | | ROHC | | ROHC |
| Compressor | | Compressor | | Decompressor |
| Context 0...N | | Context 0...M | | Context 0...K | ...
+--+---------+--+ +--+---------+--+ +--+---------+--+
^ | ^ | : ^
: CID | : CID | : CID |
: 0...N | : 0...M | : 0...K |
: v : v v |
ROHC ROHC ROHC ROHC ROHC ROHC
Feedback Channel Feedback Channel Feedback Channel
Channel Channel Channel
It should be noted that each ROHC instance at an IP interface therefore has its own context and CID space, and it must be ensured that the CID size of the corresponding decompressor at the other end of the ROHC channel is not smaller than the CID space of the compressor.
IPインタフェースにおける各ROHCインスタンスは、したがって、独自のコンテキストとCID空間を有することに留意すべきである、ROHCチャンネルの他端に対応する逆圧縮器のCIDサイズがのCID空間よりも小さくないことを保証しなければなりませんコンプレッサー。
This document has introduced and defined a number of concepts and terms for use in ROHC network integration, and explained how the various pieces relate to each other. In the following bullet list, the most important relationship conclusions are repeated:
この文書では、導入され、ROHCネットワークの統合に使用するための概念と用語の数を定義し、様々な部分が互いにどのように関係するかを説明しています。以下の箇条書きで、最も重要な関係の結論が繰り返されています。
- A network element may have one or several IP interfaces.
- ネットワーク要素は、1つのまたは複数のIPインターフェースを有していてもよいです。
- Each IP interface is connected to one or several logical layer two channels.
- 各IPインターフェースは、一つまたは複数の論理層二つのチャンネルに接続されています。
- Each IP interface may have one or several ROHC instances, either compressors, decompressors, or an arbitrary mix of both.
- それぞれのIPインターフェイスは、1つまたはいくつかのROHCインスタンス、圧縮、解凍、または両方の任意の組み合わせのいずれかを有していてもよいです。
- For each ROHC instance, there is exactly one ROHC channel, and optionally exactly one ROHC feedback channel.
- 各ROHCインスタンスについて、正確に一つのROHCチャネル、および必要に応じて正確に一つのROHCフィードバックチャネルが存在します。
- How ROHC channels and ROHC feedback channels are realized through the available logical layer two channels will vary, and there is therefore no general relation between ROHC instances and logical layer two channels. ROHC instances map only to ROHC channels and ROHC feedback channels.
- どのようにROHCチャネル及びROHCフィードバックチャネルは、2つのチャネルが変化するであろう利用可能な論理層を介して実現され、ROHCインスタンスと論理層二つのチャネルの間には一般的な関係性があるれていません。 ROHCインスタンスはROHCチャンネルとROHCのフィードバックチャネルにマッピングされます。
- Each compressor owns its own context identifier (CID) space, which is the multiplexing mechanism it uses when sending compressed header packets to its corresponding decompressor. That CID space thus defines how many compressed packet streams can be concurrently sent over the ROHC channel allocated to the compressor/decompressor peers.
- 各コンプレッサーは、その対応する逆圧縮器に圧縮ヘッダーパケットを送信するときに使用する多重化機構である、独自のコンテキスト識別子（CID）空間を所有しています。そのCID空間は、このように多くの圧縮されたパケットストリームを同時にコンプレッサ/デコンプレッサピアに割り当てられたROHCチャネルを介して送信することができる方法を定義します。
This section will address how the conceptual aspects discussed above affect implementations of ROHC.
このセクションでは、上述の概念的な側面がROHCの実装をどのように影響するか対処します。
ROHC is defined as a general header compression framework on top of which compression profiles can be defined for each specific set of headers to compress. Although the framework holds a number of important mechanisms, the separation between framework and profiles is mainly a separation from a standardization point of view, to indicate what must be common to all profiles, what must be defined by all profiles, and what are profile-specific details. To implement the framework as a separate module is thus not an obvious choice, especially if one wants to use profile implementations from different vendors. However, optimized implementations will probably separate the common parts and implement those in a ROHC framework module, and add profile modules to that.
ROHCは、圧縮プロファイルは、圧縮するヘッダの各特定のセットのために定義することができるの上に、一般的なヘッダ圧縮フレームワークとして定義されます。フレームワークは重要な機構の数を保持しているが、フレームワークおよびプロファイルとの間の分離は、主ビューの標準化の点から分離され、すべてのプロファイルによって定義されなければならないものすべてのプロファイルに共通でなければならないものを示し、何がプロフィール - でありします具体的な詳細。別のモジュールは、このように明白な選択ではないように、1つは、異なるベンダーのプロファイルの実装を使用したい場合は特に、フレームワークを実装します。しかし、最適化された実装は、おそらく共通部分を分離し、ROHCフレームワークモジュールのものを実装し、それにプロファイルモジュールを追加します。
A ROHC instance might thus consist of various pieces of implementation modules, profiles, and potentially also a common ROHC module, possibly from different vendors. If vendor and implementation version information is made available for network management purposes, this should thus be done on a per-profile basis, and potentially also for the instance as a whole.
ROHCのインスタンスは、このように、おそらく異なるベンダーからの、また潜在的に実装モジュール、プロファイル、および共通ROHCモジュールのさまざまな部分から成るかもしれません。ベンダーと実装バージョン情報をネットワーク管理の目的のために利用可能にされる場合、これは、このように、プロファイルごとに行われ、潜在的にも全体として例えばすべきです。
The clear understanding of ROHC channels and their relations to IP interfaces and the physical medium, plays a critical role in ensuring secure usage of ROHC. This document is therefore a valuable adjunct to the Security Considerations found in RFC 3095 and other ROHC specifications. However, as it just reviews information and definitions, it does not add new security issues to the ROHC protocol specifications.
IPインタフェースと物理媒体へのROHCチャンネルとその関係の明確な理解は、ROHCの安全な使用を確保する上で重要な役割を果たしています。従って、この文書はRFC 3095で見つかったセキュリティ上の考慮事項およびその他のROHC仕様に貴重な補助です。それだけの情報と定義を見直ししかし、それはROHCプロトコル仕様に新たなセキュリティ上の問題を追加しません。
Thanks to Juergen Quittek, Hans Hannu, Carsten Bormann, and Ghyslain Pelletier for fruitful discussions, improvement suggestions, and review. Thanks also to Peter Eriksson for doing a language review.
実りある話し合い、改善提案、レビューのためのユルゲンQuittek、ハンス・ハンヌ、カルステンボルマン、およびGhyslainペルティエに感謝します。言語のレビューを行うためにも、ピーター・エリクソンのおかげ。
[RFC-3095] 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.
[RFC-3095]ボルマン、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月。
Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea Sweden
ラース・エリックジョンソン、エリクソンABボックス920 SE-971 28ルーレオスウェーデン
Phone: +46 920 20 21 07 Fax: +46 920 20 20 99 EMail: lars-erik.jonsson@ericsson.com
電話：+46 920 20 21 07ファックス：+46 920 20 20 99 Eメール：lars-erik.jonsson@ericsson.com
Copyright (C) The Internet Society (2004). 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.
著作権（C）インターネット協会（2004）。この文書では、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機能のための基金は現在、インターネット協会によって提供されます。