[要約] 要約： RFC 3759は、ROHC（Robust Header Compression）の用語とチャネルマッピングの例について説明しています。ROHCは、ネットワーク上でヘッダの圧縮を行うためのプロトコルであり、効率的なデータ転送を実現します。目的： RFC 3759の目的は、ROHCの用語とチャネルマッピングの理解を深め、ROHCの実装と運用に役立つ情報を提供することです。
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
堅牢なヘッダー圧縮（ROHC）：用語とチャネルマッピングの例
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）The Internet Society（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で提示された用語と概念を明確にすることを目的としています。RFC3095は、堅牢なヘッダー圧縮（ROHC）のプロファイルを備えた提案された標準フレームワークを定義しています。この標準では、理解するのが難しいかもしれないさまざまな概念を導入し、特にヘッダー圧縮が使用される周囲の環境と正しく関連することができます。このドキュメントは、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では、4つの圧縮プロファイル[RFC-3095]とともに、堅牢なヘッダー圧縮（ROHC）標準フレームワークが定義されています。標準内でさまざまな概念が導入されており、それはすべて非常に広範囲に定義され説明されているわけではありません。これは、標準を理解しようとするときに簡単に障害となる可能性があります。これは特に、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インターフェイスなど、他の用語とどのように関連するかを明確にすることを意味します。このドキュメントの明示的な目標の1つは、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チャネルとの間には1対1の関係があります。セクション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チャネルの間には1対1の関係があり、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.
双方向圧縮操作を可能にするには、分解器から対応するコンプレッサーへのフィードバックデータのために、論理的なポイントツーポイント接続を提供する必要があります。このような論理チャネルは、Decompressorからコンプレッサーまでの単一方向にデータを運ぶだけで、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の側面を考慮すると、一般的でよく理解された、よく定義された用語が欠落しているため、不必要な混乱が簡単に作成されます。このドキュメントの主要な目標の1つは、ヘッダー圧縮ネットワーク統合の問題について議論する際に使用する優先用語を定義することです。
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 IDがあり、インターフェイスの下に隠されたリンクテクノロジーとは無関係に、共通のネットワークインターフェイス抽象化を提供します。このドキュメントの残りの部分を通して、そのようなインターフェイスは「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インターフェイスを実装できますが、リンクテクノロジーが異なると異なる特性があり、さまざまな手段で通信を提供します。ただし、すべてのLinkテクノロジーは、IPインターフェイスに出入りするデータを送信および/または受信する一般的な機能を提供します。通信する共通の能力を視覚化する一般的な方法は、リンクによって提供される1つまたは複数の論理通信チャネルとして想像することです。各チャネルは、双方向または単方向のいずれかです。このような論理的なポイントツーポイント接続は、このドキュメントの残りの部分を通して、双方向または単方向のいずれかの「チャネル」と呼ばれます。この「チャネル」の定義は、セクション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.
このような1つの単方向チャネルを使用したポイントツーポイントリンクの典型的な例は、衛星リンクです。リターンパスが存在しないため、ここでは一方向のヘッダー圧縮のみを適用できます。
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つの双方向チャネルが1つある場合の自然拡張が例になります。この例では、まだ2つのエンドポイントと1つのチャネルのみがありますが、チャネルは単純に強化されて、双方向通信を可能にします。
+-----------------+ +-----------------+
| 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.
単純なポイントツーポイントリンクの例を残して、このセクションでは、2つ以上の通信ネットワーク要素を接続する双方向リンクのケースについて説明します。例を簡素化するために、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つは双方向、1つは各方向に一方向ですが、チャネル構成はもちろんarbitrary意的です。
+-----------------+ +-----------------+
| 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インスタンスは、「ROHCコンプレッサー」または「ROHC減圧器」インスタンスの2つの異なるタイプの1つであり、IPインターフェイスにはN ROHCコンプレッサーとM ROHC圧縮機を搭載できます。コンプレッサーはしばしば減圧器と共同で配置されているが、ROHCインスタンスにはコンプレッサーと減分装置の両方を含めることはできないことに注意する必要があります。両方が存在する場合、それらは2つの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つのサブセクションでは、2種類のROHCインスタンスとその外部インターフェイスについて説明し、セクション5と6は、これらのインターフェイスを介した「ROHCチャネル」と「ROHCフィードバックチャネル」を通じてどのように実現されるかについて説明します。セクション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）：圧縮パケットは、コンプレッサーからCOを介して送信されます。これは、常にROHCチャネルの入力端に接続されています（セクション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）：対応する[オプション]減圧器からのフィードバックは、FIを介してコンプレッサーによって受信されます。減圧器からコンプレッサーにフィードバックを送信する手段がない場合、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）：圧縮パケットは、CIを介して減圧装置によって受信されます。CIは、常にROHCチャネルの出力端に接続されています（セクション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）：対応するコンプレッサー[オプション]へのフィードバックは、コンプレッサーからFOを介して送信されます。減圧器からコンプレッサーにフィードバックを送信する手段がない場合、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チャネルには、1つの単一のROHCコンプレッサーインスタンスのCOに接続された1つの入力エンドポイントと、1つの単一のROHC分解器インスタンスのCIに接続された1つの単一の出力エンドポイントがあります。したがって、この方法でROHCチャネルは、1つのROHCコンプレッサーと1つのROHC分解器に論理的に専用している必要があります。これ以降、ROHCピアと呼ばれ、ROHCチャネルと2つのROHCコンプレッサー/分解器ピアの間に1対1のマッピングを作成します。
+--------------+ --->-->-->-->--- +--------------+
| | -> 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チャネルはそのチャネルの1つの通信方向のみを表します。双方向チャネルの場合、一般的なケースは、各方向に1つの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フィードバックチャネルには、1つの単一の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フィードバックチャネルから論理的に分離する理由は、フィードバックの処理のための一般性です。ROHCは、[RFC-3095、セクション5.2.1]で説明されているように、フィードバック輸送の実現に柔軟性を生み出す論理的分離を仮定して設計されています。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.
このセクションでは、1つの双方向チャネルが一方向に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.
このセクションでは、各方向に1つのROHCチャネルを表すように双方向チャネルがどのように構成されているかを示し、同時に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チャネルの圧縮ヘッダーパケットの間にフィードバックが送信されるか、ROHCのフィードバック実現例4-6 [RFC-3095、44ページ]で説明されています。ここでは、decompressor AからコンプレッサーAからコンプレッサーAへのフィードバックがFO（a） - > pi（b）を介して送信され、ROHCチャネルBの圧縮パケットでピギーバックされ、PO（b） - > fi（a）を介してコンプレッサーAに配信されます。したがって、論理ROHCフィードバックチャネルは、コンプレッサーBのPI入力からDecompressor BのPO出力へと提供されます。この写真では、DecompressorsのPOとFOが交換され、図面を簡素化することに注意してください。
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 [RFC-3095、44ページ]のフィードバック実現例1-3で説明したように、両方向に独自の専用チャネルで送信されます。この構成では、ROHCのピギーバック/散在メカニズムは使用されず、Pi/PO接続は開いたままになります（「O」でマークされています）。この写真では、AインスタンスのFI/PIとPO/FOが描画を簡素化するように交換されている一方で、Bインスタンスは水平にミラーリングされていることに注意する必要があります。
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インターフェイスがあり、1つのIPインターフェイスに複数の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インターフェイスは、1つまたは複数の論理レイヤー2チャネルに接続されています。
- 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インスタンスには、1つのROHCチャネルが1つだけ、オプションで1つの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インスタンスと論理レイヤー2チャネルの間に一般的な関係はありません。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は、圧縮する特定のヘッダーセットごとに圧縮プロファイルを定義できる上の一般的なヘッダー圧縮フレームワークとして定義されます。フレームワークには多くの重要なメカニズムがありますが、フレームワークとプロファイルの分離は、主に標準化の観点からの分離であり、すべてのプロファイルに共通する必要があるもの、すべてのプロファイルによって定義されなければならないもの、およびプロファイルであるものを示します。具体的な詳細。したがって、フレームワークを別のモジュールとして実装することは、特に異なるベンダーのプロファイル実装を使用したい場合、明らかな選択ではありません。ただし、最適化された実装では、おそらく共通のパーツを分離し、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.
ROHCチャネルの明確な理解とIPインターフェイスと物理媒体との関係は、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.
Juergen Quittek、Hans Hannu、Carsten Bormann、およびGhyslain Pelletierに感謝し、実り多い議論、改善の提案、レビューをしてくれたことに感謝します。言語レビューをしてくれたPeter Erikssonにも感謝します。
[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] 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、 "堅牢なヘッダー圧縮（ROHC）：フレームワークと4つのプロファイル：RTP、UDP、ESP、および非圧縮」、RFC 3095、2001年7月。
Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea Sweden
Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea Sweden
Phone: +46 920 20 21 07
Fax: +46 920 20 20 99
EMail: 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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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エディター機能の資金は現在、インターネット協会によって提供されています。