RFC4163 日本語訳

Network Working Group                                       L-E. Jonsson
Request for Comments: 4163                                      Ericsson
Category: Informational                                      August 2005

ワーキンググループL-Eをネットワークでつないでください。 コメントを求めるイェンソンRequest: 4163年のエリクソンカテゴリ: 情報の2005年8月

                   RObust Header Compression (ROHC):
               Requirements on TCP/IP Header Compression

体力を要しているヘッダー圧縮(ROHC): TCP/IPヘッダー圧縮に関する要件

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 (2005).

Copyright(C)インターネット協会(2005)。

Abstract

要約

   This document contains requirements on the TCP/IP header compression
   scheme (profile) to be developed by the RObust Header Compression
   (ROHC) Working Group.  The document discusses the scope of TCP
   compression, performance considerations, assumptions about the
   surrounding environment, as well as Intellectual Property Rights
   concerns.  The structure of this document is inherited from RFC 3096,
   which defines IP/UDP/RTP requirements for ROHC.

このドキュメントはRObust Header Compression(ROHC)作業部会によって開発されるというTCP/IPヘッダー圧縮技術(プロフィール)に関する要件を含んでいます。 ドキュメントはTCP圧縮の範囲について議論します、性能問題、周囲の環境に関する仮定、Intellectual Property Rights関心と同様に。 このドキュメントの構造はRFC3096から引き継がれます。(RFCはROHCのためのIP/UDP/RTP要件を定義します)。

Table of Contents

目次

   1. Introduction ....................................................2
   2. Header Compression Requirements .................................2
      2.1. Impact on Internet Infrastructure ..........................2
      2.2. Supported Headers and Kinds of TCP Streams .................3
      2.3. Performance Issues .........................................4
      2.4. Requirements Related to Link Layer Characteristics .........6
      2.5. Intellectual Property Rights (IPR) .........................7
   3. Security Consideration ..........................................7
   4. IANA Considerations .............................................7
   5. Acknowledgements ................................................7
   6. Informative References ..........................................7

1. 序論…2 2. ヘッダー圧縮要件…2 2.1. インターネットインフラストラクチャで影響を与えてください…2 2.2. TCPの支持されたヘッダーと種類は流れます…3 2.3. パフォーマンス問題…4 2.4. 要件はリンクレイヤの特性に関連しました…6 2.5. 知的所有権は(IPR)を正します…7 3. セキュリティの考慮…7 4. IANA問題…7 5. 承認…7 6. 有益な参照…7

Jonsson                      Informational                      [Page 1]

RFC 4163              Requirements on ROHC TCP/IP            August 2005

ROHC TCP/IP2005年8月に関するイェンソン情報[1ページ]のRFC4163Requirements

1.  Introduction

1. 序論

   The goal of the ROHC WG is to develop header compression schemes that
   perform well over links with high error rates and long link roundtrip
   times.  The schemes must perform well for cellular links that use
   technologies such as Wideband Code Division Multiple Access (W-CDMA),
   Enhanced Data rates for GSM Evolution (EDGE), and CDMA2000.  However,
   the schemes should also be applicable to other link technologies with
   high loss and long roundtrip times.

ROHC WGの目標は高い誤り率とのリンクの上によく振る舞って、長い間往復の回をリンクするヘッダー圧縮技術を開発することです。 計画はW-CDMA方式などの技術(W-CDMA)、GSM EvolutionのEnhanced Dataレート(EDGE)、およびCDMA2000を使用するセルリンクによく振る舞わなければなりません。 しかしながら、また、計画も高い損失と長い往復の回で他のリンク技術に適切であるべきです。

   The main objective for ROHC has been robust compression of IP/UDP/RTP
   [5], but the WG is also chartered to develop new header compression
   solutions for IP/TCP [1], [2].  Because TCP traffic, in contrast to
   RTP, has usually been sent over reliable links, existing schemes for
   TCP, [3] and [4], have not experienced the same robustness problems
   as RTP compression.  However, there are still many scenarios where
   TCP header compression will be implemented over less reliable links
   [11], [12], making robustness an important objective for the new TCP
   compression scheme.  Other, equally important, objectives for ROHC
   TCP compression are: improved compression efficiency, enhanced
   capabilities for compression of header fields including TCP options,
   and finally incorporation of TCP compression into the ROHC framework
   [6].

ROHCのための主な目標はIP/UDP/RTP[5]の体力を要している圧縮ですが、また、WGは、IP/TCP[1]([2])の新しいヘッダー圧縮解決策を見いだすためにチャーターされます。 RTPと対照して通常信頼できるリンクの上にTCP交通を送ったので、TCPの既存の計画([3]と[4])は、RTP圧縮と同じ丈夫さ問題になっていません。 しかしながら、まだ、多くのシナリオがTCPヘッダー圧縮がそれほど信頼できないリンク[11]の上に実行されるところにあります、[12]、新しいTCP圧縮技術のために丈夫さを重要な目的にして。 ROHC TCP圧縮のための他の、そして、等しく重要な目的は以下の通りです。 改良された圧縮効率、TCPオプションを含むヘッダーフィールドの圧縮、および最終的にROHC枠組み[6]へのTCP圧縮の編入のための高められた能力。

2.  Header Compression Requirements

2. ヘッダー圧縮要件

   The following requirements have, more or less arbitrarily, been
   divided into five groups.  The first group deals with requirements
   concerning the impact of a header compression scheme on the rest of
   the Internet infrastructure.  The second group defines what kind of
   headers must be compressed efficiently.  The third and fourth groups
   concern performance requirements and capability requirements that
   stem from the properties of link technologies where ROHC TCP is
   expected to be used.  Finally, the fifth section discusses
   Intellectual Property Rights related to ROHC TCP compression.

以下の要件、多少任意に持って、分割される、5つのグループ。 最初のグループはインターネット基盤の残りに関するヘッダー圧縮技術の影響に関して要件に対処します。 2番目のグループは、効率的にどういうヘッダーを圧縮しなければならないかを定義します。 3番目と4番目のグループはROHC TCPが使用されると予想されるリンク技術の特性による性能要件と信用要求事項に関係があります。 最終的に、第5セクションはROHC TCP圧縮に関連するIntellectual Property Rightsについて論じます。

2.1.  Impact on Internet Infrastructure

2.1. インターネットインフラストラクチャで影響を与えてください。

   1.  Transparency: When a header is compressed and then decompressed,
       the resulting header must be semantically identical to the
       original header.  If this cannot be achieved, the packet
       containing the erroneous header must be discarded.

1. 透明: ヘッダーが圧縮されて、次に、減圧されるとき、オリジナルのヘッダーに、結果として起こるヘッダーは意味的に同じでなければなりません。 これを達成できないなら、誤ったヘッダーを含むパケットを捨てなければなりません。

       Justification: The header compression process must not produce
       headers that might cause problems for any current or future part
       of the Internet infrastructure.

正当化: ヘッダー圧縮の過程はインターネット基盤のどんな現在の、または、将来の部分にも問題を起こすかもしれないヘッダーを作り出してはいけません。

Jonsson                      Informational                      [Page 2]

RFC 4163              Requirements on ROHC TCP/IP            August 2005

ROHC TCP/IP2005年8月に関するイェンソン情報[2ページ]のRFC4163Requirements

       Note: The ROHC WG has not found a case where "semantically
       identical" is not the same as "bitwise identical".

以下に注意してください。 「同じ状態で、bitwiseする」とき、ROHC WGは、ケースが「意味的に同じであるところ」で同じでないことがわかっていません。

   2.  Ubiquity: Must not require modifications to existing IP (v4 or
       v6) or TCP implementations.

2. 偏在: 既存のIPへの変更(v4かv6)かTCP実現を必要としてはいけません。

       Justification: Ease of deployment.

正当化: 展開の容易さ。

       Note: The ROHC WG may recommend changes that would increase the
       compression efficiency for the TCP streams emitted by
       implementations.  However, ROHC cannot assume such
       recommendations will be followed.

以下に注意してください。 ROHC WGは実現で放たれたTCPの流れのために圧縮効率を増加させる変化を推薦するかもしれません。 しかしながら、ROHCは、そのような推薦が続かれると仮定できません。

       Note: Several TCP variants are currently in use on the Internet.
       This requirement implies that the header compression scheme must
       work efficiently and correctly for all expected TCP variants.

以下に注意してください。 いくつかのTCP異形が現在、インターネットで使用中です。 この要件は、圧縮技術がすべてのために効率的に正しく働かせなければならないヘッダーがTCP異形を予想したのを含意します。

2.2.  Supported Headers and Kinds of TCP Streams

2.2. 支持されたヘッダーと種類のTCPの流れ

   1.  IPv4 and IPv6: Must support both IPv4 and IPv6.  This means that
       all expected changes in the IP header fields must be handled by
       the compression scheme, and commonly changing fields should be
       compressed efficiently.  Compression must still be possible when
       IPv6 Extensions are present in the header.  When designing the
       compression scheme, the usage of Explicit Congestion Notification
       (ECN) [10] should be considered as a common behavior.  Therefore,
       the scheme must also compress efficiently in the case when the
       ECN bits are used.

1. IPv4とIPv6: IPv4とIPv6の両方を支持しなければなりません。 これは、すべてが、圧縮技術でIPヘッダーフィールドにおける変化を扱わなければならないと予想したことを意味します、そして、一般的に職業を替えるのは効率的に圧縮されるべきです。 IPv6 Extensionsがヘッダーに存在しているとき、圧縮はまだ可能でなければなりません。 圧縮技術を設計するとき、Explicit Congestion Notification(電子証券取引ネットワーク)[10]の用法は一般的な振舞いであるとみなされるべきです。 したがって、また、計画は電子証券取引ネットワークビットが使用されているときの場合で効率的に圧縮しなければなりません。

       Justification: IPv4 and IPv6 will both be around for the
       foreseeable future, and Options/Extensions are expected to be
       more commonly used.  ECN is expected to have a breakthrough and
       be widely deployed, especially in combination with TCP.

正当化: IPv4とIPv6が予見できる未来の間、周囲にあるでしょう、そして、Options/拡大によって、より一般的に使用されると予想されます。 電子証券取引ネットワークは、特にTCPと組み合わせてブレークスルーを持って、広く配備されると予想されます。

   2.  Mobile IP: The kinds of headers used by Mobile IP{v4,v6} must be
       supported and should be compressed efficiently.  For IPv4 these
       include headers of tunneled packets.  For IPv6 they include
       headers containing the Routing Header and the Home Address
       Option.

2. モバイルIP: ヘッダーの種類はモバイルIPでv4、v6を使用しました。支持しなければならなくて、効率的に圧縮されるべきです。 IPv4に関しては、これらはトンネルを堀られたパケットのヘッダーを含んでいます。 IPv6に関しては、彼らはルート設定HeaderとホームAddress Optionを含むヘッダーを含んでいます。

       Justification: It is very likely that Mobile IP will be used by
       cellular devices.

正当化: モバイルIPはセル装置によって非常に使用されそうでしょう。

   3.  Generality: Must handle all headers from arbitrary TCP streams.

3. 一般性: 任意のTCPの流れからすべてのヘッダーを扱わなければなりません。

       Justification: There must be a generic scheme that can compress
       reasonably well for any TCP traffic pattern.  This does not
       preclude optimizations for certain traffic patterns.

正当化: それがどんなTCPトラフィック・パターンのためにも合理的によく圧縮できる一般的な計画があるに違いありません。 これはあるトラフィック・パターンのための最適化を排除しません。

Jonsson                      Informational                      [Page 3]

RFC 4163              Requirements on ROHC TCP/IP            August 2005

ROHC TCP/IP2005年8月に関するイェンソン情報[3ページ]のRFC4163Requirements

   4.  IPSEC: The scheme should be able to compress headers containing
       IPSEC subheaders where the NULL encryption algorithm is used.

4. IPSEC: 計画はNULL暗号化アルゴリズムが使用されているIPSEC subheadersを含むヘッダーを圧縮できるべきです。

       Justification: IPSEC is expected to be used to provide necessary
       end-to-end security.

正当化: 終わりから終わりへの必要なセキュリティを提供するのにIPSECが使用されると予想されます。

       Note: It is not possible to compress the encrypted part of an ESP
       header, nor the cryptographic data in an AH header.

以下に注意してください。 超能力ヘッダーのコード化された一部、およびAHヘッダーの暗号のデータを圧縮するのは可能ではありません。

   5.  TCP: All fields supported by [4] should be handled with efficient
       compression, as should be the cases when the SYN, FIN or TCP ECN
       [10] bits are set.

5. TCP: [4]によって支持されたすべての分野が効率的な圧縮で扱われるべきです、SYN、FINまたはTCP ECN[10]ビットが用意ができているとき、そうであるべきであるように。

       Justification: These bits are expected to be commonly used.

正当化: これらのビットによって一般的に使用されると予想されます。

   6.  TCP options: The scheme must support compression of packets with
       any TCP option present, even if the option itself is not
       compressed.  Further, for some commonly used options the scheme
       should also provide compression mechanisms for the options.

6. TCPオプション: オプション自体が圧縮されないでも、計画はどんなTCPオプションも存在しているパケットの圧縮を支持しなければなりません。 また、さらに、いくつかの一般的に使用されたオプションのために、計画は圧縮機構をオプションに提供するべきです。

       Justification: Because various TCP options are commonly used,
       applicability of the compression scheme would be significantly
       reduced if packets with options could not be compressed.

正当化: 様々なTCPオプションが一般的に使用されるので、オプションがあるパケットを圧縮できないなら、圧縮技術の適用性はかなり減少するでしょうに。

       Note: Options that should be compressed are:
                     - Selective Acknowledgement (SACK), [8], [9]
                     - Timestamp, [7]

以下に注意してください。 圧縮されるべきであるオプションは以下の通りです。 - 選択している承認(袋)、[8]、[9]--タイムスタンプ[7]

2.3.  Performance Issues

2.3. パフォーマンス問題

   1.  Performance/Spectral Efficiency: The scheme must provide low
       relative overhead under expected operating conditions;
       compression efficiency should be better than for RFC 2507 [4]
       under equivalent operating conditions.

1. パフォーマンス/スペクトル効率: 計画は低い相対的なオーバーヘッドを予想された運転条件の下に提供しなければなりません。 圧縮効率はRFC2507[4]より同等な運転条件の下で良いはずです。

       Justification: Spectrum efficiency is a primary goal.

正当化: スペクトル効率は第一の目標です。

       Note: The relative overhead is the average header overhead
       relative to the payload.  Any auxiliary (e.g., control or
       feedback) channels used by the scheme should be taken into
       account when calculating the header overhead.

以下に注意してください。 相対的なオーバーヘッドはペイロードに比例した平均したヘッダーオーバーヘッドです。 ヘッダーオーバーヘッドについて計算するとき、計画によって使用されるどんな補助(例えば、コントロールかフィードバック)のチャンネルも考慮に入れられるべきです。

   2.  Losses between compressor and decompressor: The scheme should
       make sure losses between compressor and decompressor do not
       result in losses of subsequent packets, or cause damage to the
       context that results in incorrect decompression of subsequent
       packet headers.

2. コンプレッサーと減圧装置の間の損失: 計画は、コンプレッサーと減圧装置の間の損失がその後のパケットの損失をもたらさないのを確実にするべきであるか、またはその後のパケットのヘッダーの不正確な減圧をもたらす文脈に損害を与えるべきです。

Jonsson                      Informational                      [Page 4]

RFC 4163              Requirements on ROHC TCP/IP            August 2005

ROHC TCP/IP2005年8月に関するイェンソン情報[4ページ]のRFC4163Requirements

       Justification: Even though link layer retransmission in most
       cases is expected to almost eliminate losses between compressor
       and decompressor, there are still many scenarios where TCP header
       compression will be implemented over less reliable links [11],
       [12].  In such cases, loss propagation due to header compression
       could affect certain TCP mechanisms that are capable of handling
       some losses; loss propagation could also have a negative impact
       on the performance of TCP loss recovery.

正当化: リンクレイヤ「再-トランスミッション」がコンプレッサーと減圧装置の間の損失をほとんど排除すると多くの場合予想されますが、多くのシナリオがTCPヘッダー圧縮がそれほど信頼できないリンク[11]の上に実行されるところにまだあります、[12]。 そのような場合、ヘッダー圧縮による損失伝播はいくつかの損失を扱うことができるあるTCPメカニズムに影響するかもしれません。 また、損失伝播はTCP損失回復の性能のときにマイナスの影響があることができました。

   3.  Residual errors in compressed headers: Residual errors in
       compressed headers may result in delivery of incorrectly
       decompressed headers not only for the damaged packet itself, but
       also for subsequent packets, because errors may be saved in the
       context state.  For TCP, the compression scheme is not required
       to implement explicit mechanisms for residual error detection,
       but the compression scheme must not affect TCP's end-to-end
       mechanisms for error detection.

3. 圧縮されたヘッダーの見逃し誤り: 圧縮されたヘッダーの見逃し誤りは破損しているパケット自体だけではなく、その後のパケットのために不当に減圧されたヘッダーのも配送をもたらすかもしれません、誤りが文脈状態に取っておかれるかもしれないので。 TCPに関しては、圧縮技術は見逃し誤り検出のために明白なメカニズムを実行するのに必要ではありませんが、圧縮技術は誤り検出のための終わりから終わりへのTCPのメカニズムに影響してはいけません。

       Justification: For links carrying TCP traffic, the residual error
       rate is expected to be insignificant.  However, residual errors
       may still occur, especially in the end-to-end path.  Therefore,
       it is crucial that TCP is not prevented from handling these.

正当化: TCP交通を運ぶリンクに関しては、見逃し誤りレートが無意味にであると予想されます。 しかしながら、見逃し誤りは起こるかもしれません。まだ、終わらせる終わりの経路は特に起こっています。 したがって、TCPがこれらを扱ってもよいのは、重要です。

       Note: This requirement implies that the TCP checksum must be
       carried unmodified in all compressed headers.

以下に注意してください。 この要件は、すべての圧縮されたヘッダーで変更されていなくTCPチェックサムを運ばなければならないのを含意します。

       Note: The error detection mechanism in TCP may be able to detect
       residual bit errors, but the mechanism is not designed for this
       purpose, and might actually provide rather weak protection.
       Therefore, although it is not a requirement of the compression
       scheme, it should be possible for the decompressor to detect
       residual errors and discard such packets.

以下に注意してください。 TCPの誤り検出メカニズムが残りの噛み付いている誤りを検出できるかもしれませんが、メカニズムは、このために設計されていなくて、実際にかなり弱い保護を提供するかもしれません。 したがって、それは圧縮技術の要件ではありませんが、減圧装置が見逃し誤りを検出して、そのようなパケットを捨てるのは、可能であるべきです。

   4.  Short-lived TCP transfers: The scheme should provide mechanisms
       for efficient compression of short-lived TCP transfers,
       minimizing the size of context initiation headers.

4. 短命なTCPは移します: 文脈開始ヘッダーのサイズを最小にして、計画は短命なTCP転送の効率的な圧縮にメカニズムを提供するべきです。

       Justification: Many TCP transfers are short-lived.  This may lead
       to a low gain for header compression schemes that, for each new
       packet stream, requires full headers to be sent initially and
       allows small compressed headers only after the initialization
       phase.

正当化: 多くのTCP転送が短命です。 これはヘッダー圧縮技術のためのそれぞれの新しいパケットの流れに完全なヘッダーが初めは送られるのが必要であり、初期設定段階の後にだけ小さい圧縮されたヘッダーを許容する低い利得に通じるかもしれません。

       Note: This requirement implies that mechanisms for building new
       contexts that are based on information from previous contexts or
       for concurrent packet streams to share context information should
       be considered.

以下に注意してください。 この要件が、新しい関係にそれを建てるためのメカニズムが前の文脈からの情報に基づいているのを含意するか、または同時発生のパケットの流れが文脈情報を共有するのは、考えられるべきです。

Jonsson                      Informational                      [Page 5]

RFC 4163              Requirements on ROHC TCP/IP            August 2005

ROHC TCP/IP2005年8月に関するイェンソン情報[5ページ]のRFC4163Requirements

   5a. Moderate Packet Misordering: The scheme should efficiently handle
       moderate misordering (2-3 packets) in the packet stream reaching
       the compressor.

5a。 パケットMisorderingを加減してください: 計画は、コンプレッサーに達しながら、効率的に、パケットの流れにおける適度のmisordering(2-3 パケット)を扱うべきです。

       Justification: This kind of misordering is common.

正当化: この種類のmisorderingは一般的です。

   5b. Packet Misordering: The scheme must be able to correctly handle
       packet misordering and preferably compress when misordered
       packets are in the TCP stream reaching the compressor.

5b。 パケットMisordering: misorderedパケットがTCPの流れ中であるときに、計画は、コンプレッサーに達しながら、正しくパケットmisorderingと望ましくは湿布を扱うことができなければなりません。

       Justification: Misordering happens regularly in the Internet.
       However, because the Internet is engineered to run TCP reasonably
       well, excessive misordering will not be common and need not be
       handled with optimum efficiency.

正当化: Misorderingはインターネットで定期的に起こります。 しかしながら、インターネットが合理的にTCPをよく動かすために設計されるので、過度のmisorderingは一般的でなく、最適な効率で扱われる必要はありません。

   6.  Processing delay: The scheme should not contribute significantly
       to the system delay budget.

6. 処理遅れ: 計画はシステム遅れ予算にかなり貢献するべきではありません。

2.4.  Requirements Related to Link Layer Characteristics

2.4. リンクレイヤの特性に関連する要件

   1.  Unidirectional links: Must be possible to implement (possibly
       with less efficiency) without explicit feedback messages from
       decompressor to compressor.

1. 単方向はリンクされます: 明白なフィードバックメッセージなしで減圧装置からコンプレッサーまで実行するのにおいて(ことによるとより少ない効率で)可能でなければならなくなってください。

       Justification: There are links that do not provide a feedback
       channel or where feedback is not desirable for other reasons.

正当化: 提供しないか、またはフィードバックが他の理由でフィードバックチャンネルが望ましくないリンクがあります。

   2.  Link delay: Must operate under all expected link delay
       conditions.

2. 遅れをリンクしてください: すべての予想されたリンク遅れ条件のもとで作動しなければなりません。

   3.  Header compression coexistence: The scheme must fit into the ROHC
       framework together with other ROHC profiles (e.g., [6]).

3. ヘッダー圧縮共存: 計画は他のROHCプロフィールと共にROHC枠組みに収まらなければなりません。(例えば、[6])。

   4.  Note on misordering between compressor and decompressor:

4. コンプレッサーと減圧装置の間でmisorderingするとき以下に注意してください。

       When compression is applied over tunnels, misordering often
       cannot be completely avoided.  The header compression scheme
       should not prohibit misordering between compressor and
       decompressor, as it would therefore not be applicable in many
       tunneling scenarios.  However, in the case of tunneling, it is
       usually possible to get misordering indications.  Therefore, the
       compression scheme does not have to support detection of
       misordering, but can assume that such information is available
       from lower layers when misordering occurs.

圧縮がトンネルの上に適用されるとき、完全にmisorderingをしばしば避けることができるというわけではありません。 ヘッダー圧縮技術は、コンプレッサーと減圧装置の間でmisorderingするのを禁止するべきではありません、したがって、それは多くのトンネリングシナリオで適切でないでしょう。 しかしながら、トンネリングの場合では、通常、それは、指摘をmisorderingしながら、得るのにおいて可能です。 したがって、圧縮技術は、misorderingの検出を支持する必要はありませんが、misorderingがいつ起こるかというそのような情報が下層から利用可能であると仮定できます。

Jonsson                      Informational                      [Page 6]

RFC 4163              Requirements on ROHC TCP/IP            August 2005

ROHC TCP/IP2005年8月に関するイェンソン情報[6ページ]のRFC4163Requirements

2.5.  Intellectual Property Rights (IPR)

2.5. 知的所有権(IPR)

   The ROHC WG must spend effort to achieve a high degree of confidence
   that there are no known IPR claims that cover the final compression
   solution for TCP.

ROHC WGはTCPの最終的な圧縮対策をカバーするIPRクレームが知られていない高度の信用を達成するための努力を費やさなければなりません。

   Justification: Currently there is no TCP header compression scheme
   available that can efficiently compress the packet headers of modern
   TCP, e.g., with SACK, ECN, etc.  ROHC is expected to fill this gap by
   providing a ROHC TCP scheme that is applicable in the wide area
   Internet, not only over error-prone radio links.  It must thus
   attempt to be as future-proof as possible, and only unencumbered
   solutions, or solutions where the terms of any IPR are such that
   there is no hindrance on implementation and deployment, will be
   acceptable to the Internet at large.

正当化: 現在、効率的に近代的なTCPのパケットのヘッダーを圧縮できる利用可能などんなTCPヘッダー圧縮技術もありません、例えば、SACK、電子証券取引ネットワークなどで ROHCが誤り傾向があるラジオリンクの上でだけ適切であるのではなく、広い領域インターネットで適切なROHC TCP計画を提供することによってこの不足をいっぱいにすると予想されます。 その結果、可能で、邪魔されないだけの解決策、またはどんなIPRの用語もそのようなものであるので実現と展開には妨害が全くない解決策が全体のインターネットに許容できるようになるので、それは、未来の耐としてあるのを試みなければなりません。

3.  Security Consideration

3. 警備上の配慮

   A protocol specified to meet these requirements must be able to
   compress packets containing IPSEC headers according to the IPSEC
   requirement, 2.2.4.  There may be other security aspects to consider
   in such protocols.  This document by itself, however, does not add
   any security risks.

これらの必要条件を満たすために指定されたプロトコルがIPSEC要件に従ってIPSECヘッダーを含むパケットを圧縮できなければならない、2.2、.4 そのようなプロトコルで考える他のセキュリティ局面があるかもしれません。 しかしながら、それ自体でこのドキュメントは少しのセキュリティ危険も加えません。

4.  IANA Considerations

4. IANA問題

   A protocol that meets these requirements will require the IANA to
   assign various numbers.  This document by itself, however, does not
   require any IANA involvement.

これらの必要条件を満たすプロトコルは、IANAが様々な数を割り当てるのを必要とするでしょう。 しかしながら、それ自体でこのドキュメントは少しのIANAかかわり合いも必要としません。

5.  Acknowledgements

5. 承認

   This document has evolved through fruitful discussions with and input
   from Gorry Fairhurst, Carsten Bormann, Mikael Degermark, Mark West,
   Jan Kullander, Qian Zhang, Richard Price, and Aaron Falk.  The
   document quality was significantly improved thanks to Peter Eriksson,
   who made a thorough linguistic review.

このドキュメントはゴーリーFairhurst、カルステン・ボルマン、マイケル・デーゲルマルク、マーク西洋、ジャンKullander、チエン・チャン、リチャードPrice、およびアーロン・フォークからの有意義な論議と入力で発展しました。 ドキュメント品質はピーター・エリクソンのおかげでかなり改良されていました。エリクソンは、徹底的な言語学のレビューをしました。

   Last, but not least, Ghyslain Pelletier and Kristofer Sandlund served
   as committed working group document reviewers.

最後、しかし、特に、GhyslainペレティアとクリストファSandlundは遂行されたワーキンググループのドキュメント評論家として勤めました。

6.  Informative References

6. 有益な参照

   [1]  Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[1] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。

   [2]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
        September 1981.

[2] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。

Jonsson                      Informational                      [Page 7]

RFC 4163              Requirements on ROHC TCP/IP            August 2005

ROHC TCP/IP2005年8月に関するイェンソン情報[7ページ]のRFC4163Requirements

   [3]  Jacobson, V., "Compressing TCP/IP headers for low-speed serial
        links", RFC 1144, February 1990.

[3] ジェーコブソン、V.、「低速連続のリンクへのTCP/IPヘッダーを圧縮します」、RFC1144、1990年2月。

   [4]  Degermark, M., Nordgren, B., and S. Pink, "IP Header
        Compression", RFC 2507, February 1999.

[4] デーゲルマルクとM.とNordgren、B.とS.ピンク、「IPヘッダー圧縮」、RFC2507、1999年2月。

   [5]  Degermark, M., "Requirements for robust IP/UDP/RTP header
        compression", RFC 3096, July 2001.

[5] デーゲルマルク、M.、「強健なIP/UDP/RTPヘッダー圧縮のための要件」、RFC3096、2001年7月。

   [6]  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.

[6] ボルマン、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日

   [7]  Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for
        High Performance", RFC 1323, May 1992.

[7] ジェーコブソン(V.とブレーデン、R.とD.ボーマン、「高性能のためのTCP拡張子」RFC1323)は1992がそうするかもしれません。

   [8]  Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
        Selective Acknowledgement Options", RFC 2018, October 1996.

[8] マシスとM.とMahdaviとJ.とフロイド、S.とA.Romanow、「TCPの選択している承認オプション」、RFC2018、1996年10月。

   [9]  Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
        Extension to the Selective Acknowledgement (SACK) Option for
        TCP", RFC 2883, July 2000.

[9] フロイド、S.、Mahdavi、J.、マシス、M.、およびM.ポドルスキー、「TCPのための選択している承認(袋)オプションへの拡大」、RFC2883(2000年7月)。

   [10] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
        Explicit Congestion Notification (ECN) to IP", RFC 3168,
        September 2001.

[10]Ramakrishnan、K.、フロイド、S.、およびD.黒、「明白な混雑通知(電子証券取引ネットワーク)のIPへの追加」、RFC3168(2001年9月)。

   [11] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, "End-to-
        end Performance Implications of Slow Links", BCP 48, RFC 3150,
        July 2001.

[11] ダウキンズ、S.、モンテネグロ、G.、Kojo、M.、およびV.Magret、「終わりから終わりへのSlowリンクスのパフォーマンスImplications」、BCP48、RFC3150(2001年7月)。

   [12] Fairhurst, G. and L. Wood, "Advice to link designers on link
        Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, August 2002.

[12]Fairhurst、G.とL.Wood、「リンクAutomatic Repeat reQuest(ARQ)にデザイナーをリンクするというアドバイス」BCP62、RFC3366(2002年8月)。

Author's Address

作者のアドレス

   Lars-Erik Jonsson
   Ericsson AB
   Box 920
   SE-971 28 Lulea
   Sweden

ラース-エリックイェンソンエリクソンAB箱920のSE-971 28ルーレオスウェーデン

   Phone: +46 8 404 29 61
   Fax:   +46 920 996 21
   EMail: lars-erik.jonsson@ericsson.com

以下に電話をしてください。 +46 8 404、29 61、Fax: +46 920 996 21メール: lars-erik.jonsson@ericsson.com

Jonsson                      Informational                      [Page 8]

RFC 4163              Requirements on ROHC TCP/IP            August 2005

ROHC TCP/IP2005年8月に関するイェンソン情報[8ページ]のRFC4163Requirements

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントは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 9]

イェンソンInformationalです。[9ページ]