RFC3759 日本語訳
3759 RObust Header Compression (ROHC): Terminology and Channel MappingExamples. L-E. Jonsson. April 2004. (Format: TXT=50168 bytes) (Updates RFC3095) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group L-E. Jonsson Request for Comments: 3759 Ericsson Updates: 3095 April 2004 Category: Informational
ワーキンググループL-Eをネットワークでつないでください。 コメントを求めるイェンソンRequest: 3759のエリクソンアップデート: 3095 2004年4月のカテゴリ: 情報
RObust Header Compression (ROHC):
Terminology and Channel Mapping Examples
体力を要しているヘッダー圧縮(ROHC): 用語とチャンネルマッピングの例
Status of this Memo
この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.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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.
このドキュメントは、RFC3095に提示された用語と概念をはっきりさせることを目指します。 RFC3095はRObust Header Compression(ROHC)のためのプロフィールでProposed Standard枠組みを定義します。 規格は分かって、特に、正しく、ヘッダー圧縮が使用されるかもしれない周囲の環境に関連するのが難しいかもしれない様々な概念を紹介します。 このドキュメントはROHCのこれらの局面をはっきりさせるのを目的とします、MIB問題を記述するとき、ROHC例や、ROHCチャンネルや、ROHCフィードバックや、ROHC文脈などの用語と、例えば、これらの用語が一般的に使用されるネットワーク要素とIPインタフェースのように他の用語までどう関係するかについて議論して。
Jonsson Informational [Page 1] RFC 3759 ROHC Terminology and Channel Mapping Examples April 2004
イェンソン情報[1ページ]のRFC3759ROHC Terminologyとチャンネルマッピング例の2004年4月
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語。 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. ROHCの外部の用語。 . . . . . . . . . . . . . . . . . . 6 3.1. 要素とIPインタフェース. . . . . . . . . . . 6 3.2をネットワークでつないでください。 チャンネル. . . . . . . . . . . . . . . . . . . . . . . . 7 3.3。 単方向のポイントツーポイント接続の例. . . . . . 8 3.4。 双方向のポイントツーポイント接続の例. . . . . . 8 3.5。 双方向の多点リンクの例. . . . . . . . 9 3.6。 マルチチャンネルポイントツーポイント接続の例。 . . . . . . 9 4. ROHC例. . . . . . . . . . . . . . . . . . . . . . . . 10 4.1。 ROHCコンプレッサー. . . . . . . . . . . . . . . . . . . . 11 4.2。 ROHC減圧装置. . . . . . . . . . . . . . . . . . . 12 5。 ROHCは精神を集中します。 . . . . . . . . . . . . . . . . . . . . . . . . 13 6. ROHCフィードバックは.146.1を向けます。 単独のチャンネルの専用ROHC FBは例. . . . 14 6.2を向けます。 便乗したか点在しているROHC FBは例. . . . 15 6.3を向けます。 デュアル・チャンネルはROHC FBチャンネルの例. . . . . 16 7を捧げました。 ROHC文脈。 . . . . . . . . . . . . . . . . . . . . . . . . 17 8. 概要。 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. 実現含意。 . . . . . . . . . . . . . . . . . 18 10. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 19 11. 承認. . . . . . . . . . . . . . . . . . . . . . . 19 12。 有益な参照. . . . . . . . . . . . . . . . . . . . 19 13。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . 19 14。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 20
1. Introduction
1. 序論
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.
RFC3095では、RObust Header Compression(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文脈などの用語について議論して。 これは、これらの用語が他の用語までどう関係するかをはっきりさせることを特に意味します、ネットワーク要素やIPインタフェースなどのように。(MIB問題を記述するとき、例えば、インタフェースは一般的に使用されます)。 このドキュメントの1つの明確な目標は、ROHC MIB開発事業を支持して、簡素化することです。
Jonsson Informational [Page 2] RFC 3759 ROHC Terminology and Channel Mapping Examples April 2004
イェンソン情報[2ページ]のRFC3759ROHC Terminologyとチャンネルマッピング例の2004年4月
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はこれらの概念的な局面から起こるいくつかの実現含意について説明します。
2. Terminology
2. 用語
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チャンネルの間との1〜1つの関係があります。そこでは、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チャンネルの間との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チャンネルのもう一方の端に位置する同輩コンプレッサーを示します、すなわち、減圧装置が減圧するヘッダーを圧縮するコンプレッサー。
Jonsson Informational [Page 3] RFC 3759 ROHC Terminology and Channel Mapping Examples April 2004
イェンソン情報[3ページ]のRFC3759ROHC Terminologyとチャンネルマッピング例の2004年4月
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を見てください。
Jonsson Informational [Page 4] RFC 3759 ROHC Terminology and Channel Mapping Examples April 2004
イェンソン情報[4ページ]のRFC3759ROHC Terminologyとチャンネルマッピング例の2004年4月
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を見てください。
Jonsson Informational [Page 5] RFC 3759 ROHC Terminology and Channel Mapping Examples April 2004
イェンソン情報[5ページ]のRFC3759ROHC Terminologyとチャンネルマッピング例の2004年4月
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コンプレッサーまでひたむきなフィードバックチャンネルは論理的な層twoのチャンネルです、単にフィードバックパケットを伝えるのにおいて、使用されています。 例に関してセクション6.1と6.3を見てください。
3. ROHC External Terminology
3. ROHCの外部の用語
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つの主要な目標はヘッダー圧縮ネットワーク集積問題について議論するとき使用する都合のよい用語を定義することです。
3.1. Network Elements and IP Interfaces
3.1. ネットワーク要素とIPインタフェース
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".
ネットワーク要素は1かいくつかのネットワーク・インターフェースを通って交信します、MIB仕様で定義されるように。ネットワーク・インターフェースはしばしばネットワークマネージメントを受けることがあります。 すべての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 |
+---------------+ +---------------+ ...
+-----------------------------------------------------+ | ネットワーク要素| +---------------+--+---------------+------------------+ | IP| | IP| | インタフェース| | インタフェース| +---------------+ +---------------+ ...
The next section builds on this top level hierarchy by looking at what is below an IP interface.
次のセクションは、この最高平らな階層構造にIPインタフェースの下にあるものを見ることによって、建てられます。
Jonsson Informational [Page 6] RFC 3759 ROHC Terminology and Channel Mapping Examples April 2004
イェンソン情報[6ページ]のRFC3759ROHC Terminologyとチャンネルマッピング例の2004年4月
3.2. Channels
3.2. チャンネル
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インタフェースからの/にデータを送る、そして/または、受け取る一般的な能力を提供します。 交信する一般的な能力を想像する一般的な方法は1、それぞれのチャンネルが2方向上である場合があるリンクによって提供されたいくつかの論理的な通信チャネルまたは単方向としてそれを思い描くことです。 そのような論理的な二地点間接続は「チャンネル」と呼ばれて、双方向のこのドキュメントか単方向の残りの間中そうするでしょう。 セクション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|
: : : : : : : : : : : :
+-----------------------------------------------------+ | ネットワーク要素| +---------------+--+---------------+------------------+ | IP| | IP| | インタフェース| | インタフェース| ++ +-+ +-+ +----+ ++ +-+ +-+ +----+ ... |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.
1個以上のチャンネルがあるかどうかと、チャンネル(s)が/であるかどうかが双方向です、または単方向(または、両方のミックス)はリンク技術に依存しています、チャンネルが論理的に創造される方法のように。
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.
- チャンネルが両性愛者である、または、単方向? - リンクはポイントツーポイントですか? そうでなければ、下層アドレシング体系が、論理的な二地点間チャンネルを創造するのに必要です。
Jonsson Informational [Page 7] RFC 3759 ROHC Terminology and Channel Mapping Examples April 2004
イェンソン情報[7ページ]のRFC3759ROHC Terminologyとチャンネルマッピング例の2004年4月
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)の定義でわずかに機能アップされたのを覚えているべきです、基本のチャンネル概念がここで使用されている間、上で定義されるように。
3.3. A Unidirectional Point-to-Point Link Example
3.3. 単方向のポイントツーポイント接続の例
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.
1つが上記の概要から引き出すことができる可能な限り簡単なリンクの例は2の間の1個の単独の単方向のチャンネルがネットワーク要素を伝えているケースです。
+-----------------+ +-----------------+
| Network Element | | Network Element |
+-----------------+ +-----------------+
| IP | | IP |
| Interface | | Interface |
+------+ +------+ +------+ +------+
| | | |
| +--------------------------------+ |
| -> Unidirectional channel -> |
+----------------------------------------+
+-----------------+ +-----------------+ | ネットワーク要素| | ネットワーク要素| +-----------------+ +-----------------+ | IP| | IP| | インタフェース| | インタフェース| +------+ +------+ +------+ +------+ | | | | | +--------------------------------+ | | ->単方向のチャンネル->。| +----------------------------------------+
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個の単方向のチャンネルとのポイントツーポイント接続の典型的な例は衛星中継です。 どんな存在しているリターンパスもないので、単方向のヘッダー圧縮しかここに適用できません。
3.4. A Bi-directional Point-to-Point Link Example
3.4. 双方向のポイントツーポイント接続の例
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.
上記の例を1ステップより遠くに取って、自然な拡大は2の間の1個の単独の双方向のチャンネルがネットワーク要素を伝えている例でしょう。 この例には、2つの終点と1個の単独のチャンネルしかまだありませんが、チャンネルは、双方向のコミュニケーションを許容するために単に機能アップされます。
+-----------------+ +-----------------+
| Network Element | | Network Element |
+-----------------+ +-----------------+
| IP | | IP |
| Interface | | Interface |
+------+ +------+ +------+ +------+
| | | |
| +--------------------------------+ |
| <-> Bi-directional channel <-> |
+----------------------------------------+
+-----------------+ +-----------------+ | ネットワーク要素| | ネットワーク要素| +-----------------+ +-----------------+ | IP| | IP| | インタフェース| | インタフェース| +------+ +------+ +------+ +------+ | | | | | +--------------------------------+ | | <。>の双方向のチャンネル<->。| +----------------------------------------+
Jonsson Informational [Page 8] RFC 3759 ROHC Terminology and Channel Mapping Examples April 2004
イェンソン情報[8ページ]のRFC3759ROHC Terminologyとチャンネルマッピング例の2004年4月
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の上にしていた状態で適用できます、そして、圧縮技術は圧縮性能を向上させるのにリターンパスを利用できます。
3.5. A Bi-directional Multipoint Link Example
3.5. 双方向の多点リンクの例
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" <-> |
+-----------------------------------------------+
+-----------------+ +-----------------+ +-----------------+ | ネットワーク要素| | ネットワーク要素| | ネットワーク要素| +-----------------+ +-----------------+ +-----------------+ | IP| | IP| | IP| | インタフェース| | インタフェース| | インタフェース| +------+ +------+ +------+ +------+ +------+ +------+ | | | | | | | | | | | | | +-----------------+ +-----------------+ | | <。>双方向の「共有されたチャンネル」<->。| +-----------------------------------------------+
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人の独身の送付者しか見ないで、送付者の振舞いは、受信機の数から独立していて、彼らの振舞いで影響を受けないです。
3.6. A Multi-Channel Point-to-Point Link Example
3.6. マルチチャンネルポイントツーポイント接続の例
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つの単方向です、しかし、チャネル構成はもちろん任意であるかもしれません。
Jonsson Informational [Page 9] RFC 3759 ROHC Terminology and Channel Mapping Examples April 2004
イェンソン情報[9ページ]のRFC3759ROHC Terminologyとチャンネルマッピング例の2004年4月
+-----------------+ +-----------------+
| Network Element | | Network Element |
+-----------------+ +-----------------+
| IP | | IP |
| Interface | | Interface |
+-+ +---+ +---+ +-+ +-+ +---+ +---+ +-+
| | | | | | | | | | | |
| | | | | +--------------------------+ | | | | |
| | | | | <- Unidirectional channel <- | | | | |
| | | | +------------------------------+ | | | |
| | | | | | | |
| | | | | | | |
| | | +--------------------------------------+ | | |
| | | <-> Bi-directional channel <-> | | |
| | +------------------------------------------+ | |
| | | |
| | | |
| +--------------------------------------------------+ |
| -> Unidirectional channel -> |
+------------------------------------------------------+
+-----------------+ +-----------------+ | ネットワーク要素| | ネットワーク要素| +-----------------+ +-----------------+ | IP| | IP| | インタフェース| | インタフェース| +-+ +---+ +---+ +-+ +-+ +---+ +---+ +-+ | | | | | | | | | | | | | | | | | +--------------------------+ | | | | | | | | | | <。 単方向チャンネル<。| | | | | | | | | +------------------------------+ | | | | | | | | | | | | | | | | | | | | | | | +--------------------------------------+ | | | | | | <。>の双方向のチャンネル<->。| | | | | +------------------------------------------+ | | | | | | | | | | | +--------------------------------------------------+ | | ->単方向のチャンネル->。| +------------------------------------------------------+
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.
以上のように、マルチチャンネルリンクの典型的な例はセルワイヤレスのリンクです。 この例では、ヘッダー圧縮は1チャンネルあたり1個のベースで適切でしょう、双方向か単方向の方法で働いている各チャンネルのために、チャンネル所有地によって。
4. ROHC Instances
4. ROHCインスタンス
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コンプレッサー」かIPインタフェースのどちらかがN ROHCコンプレッサーとM持つことができる2の1つがROHC減圧装置であったならそうすることができます、NとMが特殊活字の数字であるところで。 コンプレッサーがしばしば減圧装置で共同見つけられていますが、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文脈地図。
Jonsson Informational [Page 10] RFC 3759 ROHC Terminology and Channel Mapping Examples April 2004
イェンソン情報[10ページ]のRFC3759ROHC Terminologyとチャンネルマッピング例の2004年4月
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の回転する度合いであることに注意されるべきであり、すなわち、彼らは「スタック視点」を示しません。
4.1. ROHC Compressors
4.1. ROHCコンプレッサー
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:
1か数個のROHCプロフィールによると、ROHCコンプレッサーインスタンスはヘッダーに圧縮をサポートします。 潜在的構成かコントロールインタフェースは別として、コンプレッサーインスタンスは、3つの入力と1回の出力でデータを受け取って、送ります、以下の図によって例証されるように:
+--------------+
-> UI -> | | -> CO ->
| ROHC |
| Compressor |
-> PI -> | | <- FI <-
+--------------+
+--------------+ ->ウイ->。| | ->CO->。| ROHC| | コンプレッサー| ->パイ->。| | <。 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を見てください)。COはいつもつなげられます。
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を通して対応する[任意の]減圧装置からのフィードバックを受け取ります(セクション6を見てください)。FIはある種のROHCフィードバックチャンネルの出力端まで接続されます(存在しているなら)。 減圧装置からコンプレッサーまでフィードバックを伝える手段が全くないとき、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を通してコンプレッサーに提供されます。 この入力が使用されているなら、それは共同見つけられた減圧装置のFOに接続されます(セクション4.2を見てください)。
Jonsson Informational [Page 11] RFC 3759 ROHC Terminology and Channel Mapping Examples April 2004
イェンソン情報[11ページ]のRFC3759ROHC Terminologyとチャンネルマッピング例の2004年4月
4.2. ROHC Decompressors
4.2. ROHC減圧装置
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:
1か数個のROHCプロフィールによると、ROHC減圧装置インスタンスはヘッダーに減圧をサポートします。 潜在的構成かコントロールインタフェースは別として、減圧装置インスタンスは、1つの入力と3回の出力でデータを受け取って、送ります、以下の図によって例証されるように:
+--------------+
-> CI -> | | -> DO ->
| ROHC |
| Decompressor |
<- FO <- | | -> PO ->
+--------------+
+--------------+ ->CI->。| | ->は->をします。| ROHC| | 減圧装置| <。 フォ<。| | ->ポー->+--------------+
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を通して圧縮されたパケットを受け取ります(セクション5を見てください)。CIはROHCチャンネルの出力端までいつも接続されます。
Decompressed Output (DO): Decompressed packets are delivered from
the decompressor to higher layers
through the 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を通してコンプレッサーから対応するコンプレッサー[任意の]へのフィードバックを送ります(セクション6を見てください)。FOはある種のROHCフィードバックチャンネルの入力端まで接続されます(存在しているなら)。 減圧装置からコンプレッサーまでフィードバックを伝える手段が全くないとき、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を見てください)。
Jonsson Informational [Page 12] RFC 3759 ROHC Terminology and Channel Mapping Examples April 2004
イェンソン情報[12ページ]のRFC3759ROHC Terminologyとチャンネルマッピング例の2004年4月
5. ROHC Channels
5. ROHCチャンネル
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減圧装置例のCIにつなげられた1つただ一つのROHCコンプレッサー例、および1の単一の出力終点のCOにつなげられた1つの単一の入力終点があります。 その結果、ROHCチャンネルと2人のROHCコンプレッサー/減圧装置同輩の間で1〜1つのマッピングを作成しながら、今後ROHC同輩と呼ばれた1個のROHCコンプレッサーと1つのROHC減圧装置にROHCチャンネルを論理的にこのように専念させなければなりません。
+--------------+ --->-->-->-->--- +--------------+ | | -> CO -> ROHC Channel -> CI -> | | | ROHC | --->-->-->-->--- | ROHC | | Compressor | | Decompressor | | | | | +--------------+ +--------------+
+--------------+ --->-->-->-->-- +--------------+ | | ->CO->ROHCチャンネル->CI->。| | | ROHC| --->-->-->(>)| ROHC| | コンプレッサー| | 減圧装置| | | | | +--------------+ +--------------+
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で説明されて、例示されるように。
Jonsson Informational [Page 13] RFC 3759 ROHC Terminology and Channel Mapping Examples April 2004
イェンソン情報[13ページ]のRFC3759ROHC Terminologyとチャンネルマッピング例の2004年4月
6. ROHC Feedback Channels
6. ROHCフィードバックチャンネル
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".
様々な種類のリンク、単方向または双方向の1チャンネルのリンクの上にROHCを実行できるので、マルチチャンネルリンクと同様に、フィードバックの論理的な減圧装置からコンプレッサーまでの送信は実際の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コンプレッサー例のFIにつなげられた1つただ一つのROHC減圧装置例、および1の単一の出力終点のFOにつなげられた1つの単一の入力終点があります。
+--------------+ +--------------+ | | | | | ROHC | | ROHC | | Compressor | --<--<--<--<--<-- | Decompressor | | | <- FI <- ROHC FB Channel <- FO <- | | +--------------+ --<--<--<--<--<-- +--------------+
+--------------+ +--------------+ | | | | | ROHC| | ROHC| | コンプレッサー| --<--<--<--<(<)| 減圧装置| | | <。 FI<ROHC FBチャンネル<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フィードバックチャンネルがことによるとどう実現されるかもしれないかに関する例を全く徹底的でないいくつかに提供します。
6.1. Single-Channel Dedicated ROHC Feedback Channel Example
6.1. 単独のチャンネルのひたむきな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フィードバックチャンネルをもう片方の方向に例証します。
Jonsson Informational [Page 14] RFC 3759 ROHC Terminology and Channel Mapping Examples April 2004
イェンソン情報[14ページ]のRFC3759ROHC Terminologyとチャンネルマッピング例の2004年4月
Bi-directional channel
..................
+--------------+ : -->-->-->-->-- : +--------------+
--> |UI CO| --> : ROHC Channel : --> |CI DO| -->
| ROHC | : -->-->-->-->-- : | ROHC |
| Compressor | : : | Decompressor |
| | : --<--<--<--<-- : | |
o |PI FI| <-- : FB Channel : <-- |FO PO| o
+--------------+ : --<--<--<--<-- : +--------------+
:................:
双方向のチャンネル… +--------------+ : -->-->-->-->-- : +--------------+-->。|ウイCO| -->: ROHCは精神を集中します: -->| CIはそうします。| -->| ROHC| : -->-->-->-->-- : | ROHC| | コンプレッサー| : : | 減圧装置| | | : --<--<--<--<-- : | | o |パイFI| <-- : FBは精神を集中します: <-- |フォ・ポー| 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[RFC3095、44ページ]に関するフィードバック実現の例1-3で議論するように。 これは、ROHCの便乗/点在メカニズムが使用されていなくて、PI/PO接続がこのようにして開く(「o」で、マークされます)ままにされることを意味します。 このアプローチを使用しながら両用方法でROHC圧縮とのコミュニケーションを容易にするために、すなわち、4個の論理的な単方向のチャンネルを利用することで同じ構成をもう片方の方向に提供しなければなりません。
6.2. Piggybacked/Interspersed ROHC Feedback Channel Example
6.2. 便乗したか点在しているROHCフィードバックチャンネルの例
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| <--
+--------------+ : --<--<--<--<-- : +--------------+
:................:
双方向のチャンネル… +--------------+ : -->-->-->-->-- : +--------------+-->。|ウイCO| -->: ROHCはAにチャネルを開設します: -->| CIはそうします。| -->| ROHC| : -->-->-->-->-- : | ROHC| | コンプレッサー| : : | 減圧装置| | A| : : | A| +->。|パイFI| <。+ : : +-- |ポー・フォ| --+ | +--------------+ | : : | +--------------+ | | | : : | | | | : : | | | +--------------+ | : : | +--------------+ | +-- |フォ・ポー| --+ : : +->。|FIパイ| <。+ | ROHC| : : | ROHC| | 減圧装置| : : | コンプレッサー| | B| : --<--<--<--<-- : | B| <-- |CIをしてください。| <-- : ROHCはBにチャネルを開設します: <-- |COウイ| <-- +--------------+ : --<--<--<--<-- : +--------------+ :................:
Jonsson Informational [Page 15] RFC 3759 ROHC Terminology and Channel Mapping Examples April 2004
イェンソン情報[15ページ]のRFC3759ROHC Terminologyとチャンネルマッピング例の2004年4月
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[RFC-3095、44ページ]に関するフィードバック実現の例4-6で議論するように。 減圧装置AからコンプレッサーAまでのフィードバックは、FO(A)->を通してPI(B)であって、ROHCチャンネルBの上に圧縮されたパケットの上で便乗していた状態で送って、ここにあって、PO(B)を通したコンプレッサーAに>FI(A)を配送しました。 減圧装置B.で論理的なROHCフィードバックチャンネルをこのようにしてコンプレッサーBでのPI入力からPO出力まで提供します。図面を簡素化するために減圧装置におけるこの絵、PO、およびFOで交換されたItに注意するべきです。
6.3. Dual-Channel Dedicated ROHC Feedback Channel Example
6.3. デュアル・チャンネルはROHCフィードバックチャンネルの例を捧げました。
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 : <----------------------+
: --<--<--<--<-- :
:................:
双方向のチャンネル… +--------------+ : -->-->-->-->-- : +--------------+ ->|ウイCO| -->: ROHCはAにチャネルを開設します: -->| CIはそうします。|、-、>、| ROHC| : -->-->-->-->-- : | ROHC| | コンプレッサー| : : | 減圧装置| | A| : : | A| | | : : | | +->。|FIパイ| o : : o |ポー・フォ| --+ | +--------------+ : --<--<--<--<-- : +--------------+ | | +- : ROHCチャンネルB: <-+| | | : --<--<--<--<-- : | | | +--------------+ | :................: | +--------------+ | | <、-、|CIをしてください。| <、-+ +- |COウイ| <、-、|、|、| ROHC| | ROHC| | | | 減圧装置| 双方向のチャンネル| コンプレッサー| | | | B| .................. | B| | | | | : -->-->-->-->-- : | | | | o|ポー・フォ| -->: FBはBにチャネルを開設します: -->| FIパイ|o | | +--------------+ : -->-->-->-->-- : +--------------+ | | : : | | : --<--<--<--<-- : | +----------------------- : FBは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
この例では、それ自身のひたむきなチャンネルで両方の方向にフィードバックを送ります、例えば、ROHC[RFC-3095、44ページ]に関するフィードバック実現の例1-3で議論するように。 この構成で、ROHCの便乗/点在メカニズムは使用されていません、そして、PI/PO接続はこのようにして開く(「o」で、マークされます)ままにされます。 それはそうするべきです。
Jonsson Informational [Page 16] RFC 3759 ROHC Terminology and Channel Mapping Examples April 2004
イェンソン情報[16ページ]のRFC3759ROHC Terminologyとチャンネルマッピング例の2004年4月
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.
注意されて、A-例におけるこの絵のFI/PIとPO/FOのそれは図面を簡素化するために交換されました、B-例が水平に反映されましたがことになってください。
7. ROHC Contexts
7. ROHC文脈
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例があるかもしれなくて、それぞれのROHC例を支持して、1個のROHCチャンネルがまさにいて、任意に、1ROHCのフィードバックが精神を集中するということです。 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
+------------------------------------------------------------------+ | IPインタフェース| +---------------+----+---------------+----+---------------+--------+ | ROHC| | ROHC| | ROHC| | コンプレッサー| | コンプレッサー| | 減圧装置| | 文脈0…N| | 文脈0…M| | 文脈0…K| ... +--+---------+--+ +--+---------+--+ +--+---------+--+ ^ | ^ | : ^ : Cid| : Cid| : Cid| : 0...N| : 0...M| : 0...K| : v: vに対して| ROHC ROHC ROHC ROHC ROHC ROHCフィードバックチャンネルフィードバックチャンネルフィードバックチャンネルチャンネルチャンネルチャンネル
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スペースより小さくならないようにしなければなりません。
Jonsson Informational [Page 17] RFC 3759 ROHC Terminology and Channel Mapping Examples April 2004
イェンソン情報[17ページ]のRFC3759ROHC Terminologyとチャンネルマッピング例の2004年4月
8. Summary
8. 概要
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か数個の論理的な層twoのチャンネルに接されます。
- 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チャンネルがまさにあります、そして、任意に、ちょうど1ROHCのフィードバックは精神を集中します。
- 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フィードバックチャンネルが利用可能な論理的な層twoのチャンネルでどう実現されるかは異なるでしょう、そして、したがって、ROHC例と論理的な層twoのチャンネルとのどんな一般的な関係もありません。 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チャンネルの上にいくつの圧縮されたパケット小川を送ることができるかを定義します。
9. Implementation Implications
9. 実現含意
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枠組みのモジュールでそれらを実行して、プロフィールモジュールをそれに加えるでしょう。
Jonsson Informational [Page 18] RFC 3759 ROHC Terminology and Channel Mapping Examples April 2004
イェンソン情報[18ページ]のRFC3759ROHC Terminologyとチャンネルマッピング例の2004年4月
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モジュールからも成るかもしれません、ことによると異なった業者から。 その結果、また、業者と実現バージョン情報をネットワークマネージメント目的に利用可能にするなら、全体で例のために1プロフィールあたり1個のベースで潜在的にこれをするべきです。
10. Security Considerations
10. セキュリティ問題
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の安全な使用法を確実にすることにおいて重大な役割です。 したがって、このドキュメントはRFC3095と他のROHC仕様で見つけられたSecurity Considerationsへの貴重な付属物です。 しかしながら、ただ情報と定義を再検討するとき、それは新しい安全保障問題をROHCプロトコル仕様に追加しません。
11. Acknowledgements
11. 承認
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ペレティアをありがとうございます。 言語をするためのピーター・エリクソンにも感謝は論評します。
12. Informative References
12. 有益な参照
[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.、バーマイスター、C.、デーゲルマルク、M.、福島、H.、ハンヌ、H.、イェンソン、L-E.、Hakenberg、R.、コーレン、T.、Le、K.、リュウ、Z.、Martensson、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH.ツェン、「体力を要しているヘッダー圧縮(ROHC):」 枠組みと4個のプロフィール: 「RTP、超能力であって、解凍されたUDP」、RFC3095、7月2001日
13. Author's Address
13. 作者のアドレス
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、Fax: +46 920 20 20 99はメールされます: lars-erik.jonsson@ericsson.com
Jonsson Informational [Page 19] RFC 3759 ROHC Terminology and Channel Mapping Examples April 2004
イェンソン情報[19ページ]のRFC3759ROHC Terminologyとチャンネルマッピング例の2004年4月
14. Full Copyright Statement
14. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Jonsson Informational [Page 20]
イェンソンInformationalです。[20ページ]
一覧
スポンサーリンク
