RFC3243 日本語訳

3243 RObust Header Compression (ROHC): Requirements and Assumptionsfor 0-byte IP/UDP/RTP Compression. L-E. Jonsson. April 2002. (Format: TXT=12451 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                       L-E. Jonsson
Request for Comments: 3243                                      Ericsson
Category: Informational                                       April 2002

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

                   RObust Header Compression (ROHC):
    Requirements and Assumptions for 0-byte IP/UDP/RTP Compression

体力を要しているヘッダー圧縮(ROHC): 0バイトのIP/UDP/RTP圧縮のための要件と仮定

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 (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

Abstract

要約

   This document contains requirements for the 0-byte IP/UDP/RTP
   (Internet Protocol/User Datagram Protocol/Real-Time Transport
   Protocol) header compression scheme to be developed by the Robust
   Header Compression (ROHC) Working Group.  It also includes the basic
   assumptions for the typical link layers over which 0-byte compression
   may be implemented, and assumptions about its usage in general.

このドキュメントは0バイトのIP/UDP/RTP(インターネットのリアルプロトコル/ユーザー・データグラム・プロトコル/タイムのTransportプロトコル)ヘッダー圧縮技術がRobust Header Compression(ROHC)作業部会によって開発されるという要件を含んでいます。 また、それは0バイトの圧縮が実行されるかもしれない典型的なリンクレイヤのための基本仮定、および一般に、用法に関する仮定を含んでいます。

1.  Introduction

1. 序論

   The goal of the Robust Header Compression (ROHC) Working Group 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, using technologies such as WCDMA,
   EDGE, and CDMA-2000.  However, the schemes should also be applicable
   to other future link technologies with high loss and long roundtrip
   times.

Robust Header Compression(ROHC)作業部会の目標は高い誤り率とのリンクの上によく振る舞って、長い間往復の回をリンクするヘッダー圧縮技術を開発することです。 WCDMAや、EDGEや、CDMA-2000などの技術を使用して、計画はセルリンクによく振る舞わなければなりません。 しかしながら、また、計画も高い損失と長い往復の回で他の将来のリンク技術に適切であるべきです。

   ROHC RTP has become a very efficient, robust and capable compression
   scheme, able to compress the IP/UDP/RTP headers down to a total size
   of only one octet.  This makes ROHC RTP an excellent solution for
   future cellular environments with new air interfaces, such as WCDMA,
   making even speech services possible over IP with an insignificantly
   lower spectrum efficiency compared to existing circuit switched
   solutions.

ROHC RTPは非常に効率的で、強健でできる圧縮技術になりました、IP/UDP/RTPヘッダーを1つの八重奏だけの総サイズまで圧縮できます。 これは新しい空気インタフェースでROHC RTPを将来のセル環境の素晴らしい解決策にします、WCDMAなどのように、スピーチサービスさえ無意味に低いスペクトル効率が既存のサーキット切り換えられた解決策にたとえられている状態でIPの上で可能にして。

Jonsson                      Informational                      [Page 1]

RFC 3243        Reqs and Assumptions for 0-byte ROHC RTP      April 2002

0バイトのROHC RTP2002年4月のためのイェンソン情報[1ページ]のRFC3243Reqsと仮定

   However, all-IP cellular networks will also be built with already
   existing air interfaces such as GSM and IS-95, which are less
   flexible using radio bearers optimized for specific frame sizes
   matching the speech codecs used.  This means that not a single octet
   of header can be added without switching to the next higher fixed
   packet size supported by the link, something which is obviously very
   costly.  In the long term, this drawback should of course be
   eliminated with new, more flexible air interfaces, but in the short
   term it would be desirable if an efficiency comparable to the circuit
   switched case could also be achieved for already deployed speech
   codecs when used over the existing air interfaces.  To achieve that,
   it must be possible to completely eliminate the headers for a
   majority of the packets during normal operation, and this is the
   purpose of 0-byte header compression.  All functionality normally
   provided by the 1-octet header must then be provided by some other
   means, typically by utilizing functionality from the lower layer.  It
   is important to remember that the purpose of 0-byte header
   compression is to provide optimal efficiency for applications
   matching the link layer characteristics, not efficiency in general.

そして、しかしながら、また、オールIPセルラー・ネットワークがGSMなどの既に既存の空気インタフェースで造である、-95である、どれがラジオ運搬人を使用することでそれほどフレキシブルでないかはコーデックが使用したスピーチに合っている特定のフレーム・サイズのために最適化されました。 これは、リンク明らかに非常に(何か高価なもの)によって支持された次の、より高い固定パケットサイズに切り替わらないでヘッダーの1つの八重奏も加えることができないことを意味します。 長期で、この欠点はもちろん新しくて、よりフレキシブルな空気インタフェースで排除されるべきですが、また、既存の空気インタフェースの上で使用されると既に配備されたスピーチコーデックのためにサーキットの切り換えられたケースに匹敵する効率を達成できるなら、短期で望ましいでしょうに。 それを達成するために、パケットの大部分のために通常の操作の間、ヘッダーを完全に排除するのが可能でなければならなく、これは0バイトのヘッダー圧縮の目的です。 次に、ある他の手段で通常、1八重奏のヘッダーによって提供されたすべての機能性を提供しなければなりません、通常、下層からの機能性を利用することによって。 忘れずに一般に、効率ではなく、リンクレイヤの特性に合っているアプリケーションに最適の効率を0バイトのヘッダー圧縮の目的がことである提供するのは重要です。

   As a starting point for these requirements, the well-established
   requirements base developed in the ROHC WG has been used.  From that,
   the requirements have evolved through input from the 3GPP2 community
   and from discussions within the WG.

これらの要件のための出発点として、ROHC WGで発展する安定している要件ベースは使用されました。 それから、要件は3GPP2共同体とWGの中の議論からの入力で発展しました。

2.  Assumptions for the Applicability of 0-byte RTP Header Compression

2. 0バイトのRTPヘッダー圧縮の適用性のための仮定

   The purpose of 0-byte header compression is to provide optimal usage
   of certain links when the traffic pattern of a packet stream
   completely matches the characteristics of that link.  There are no
   assumptions that only packet streams complying with that pattern will
   occur, but optimal efficiency cannot of course be provided when this
   is not the case.

0バイトのヘッダー圧縮の目的はパケットの流れのトラフィック・パターンがそのリンクの特性に完全に合っているとあるリンクの最適の使用法を提供することです。 そのパターンに従うパケットの流れだけが起こりますが、これがそうでないときにもちろん最適の効率を提供できないという仮定が全くありません。

   To make 0-byte header compression feasible, it is assumed that lower
   layers can provide the necessary functionality needed to replace the
   1-octet headers and fulfill the requirements defined in section 3.
   An example is the synchronized nature of most cellular links, which
   can provide sequencing and timing information and make packet loss
   detection possible.

0バイトのヘッダー圧縮を可能にするように、下層が1八重奏のヘッダーを取り替えるのに必要である必要な機能性を提供して、セクション3で定義された要件を実現させることができると思われます。 例はほとんどのセルリンクの連動している自然です。(リンクは、配列とタイミング情報を提供して、パケット損失検出を可能にすることができます)。

3.  Requirements on 0-byte RTP Header Compression

3. 0バイトのRTPヘッダー圧縮に関する要件

   Since 0-byte header compression for ROHC IP/UDP/RTP is a variant of
   regular ROHC RTP compression [ROHC], these requirements are described
   as deltas to those defined in the regular RTP requirements [RTP-REQ].
   For simplicity, this section is also separated into the same three
   subsections as the requirements in [RTP-REQ], where the first deals

ROHC IP/UDP/RTPのための0バイトのヘッダー圧縮が定期的なROHC RTP圧縮[ROHC]の異形であるので、これらの要件は通常のRTP要件[RTP-REQ]で定義されたものへのデルタとして記述されています。 また、簡単さにおいて、このセクションは[RTP-REQ]の要件と同じ3つの小区分に切り離されます、どこ、1番目は取扱うか。

Jonsson                      Informational                      [Page 2]

RFC 3243        Reqs and Assumptions for 0-byte ROHC RTP      April 2002

0バイトのROHC RTP2002年4月のためのイェンソン情報[2ページ]のRFC3243Reqsと仮定

   with the impact of header compression on the rest of the Internet
   infrastructure, the second concerns the headers to be compressed, and
   the third covers efficiency and link technology related issues.

インターネット基盤の残りのヘッダー圧縮の影響で、秒は、効率とリンク技術が問題を関係づけたのが圧縮されるべきヘッダー、および3番目のカバーに関係があります。

3.1.  Impact on Internet Infrastructure

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

   The meaning of header compression is in no way changed by the
   introduction of 0-byte header compression.  No additional impact on
   the Internet infrastructure is thus allowed.  The "Transparency" and
   "Ubiquity" requirements of [RTP-REQ, section 2.1] therefore also
   apply to 0-byte RTP compression without any modifications.

ヘッダー圧縮の意味は0バイトのヘッダー圧縮の導入で決して変えられません。 インターネット基盤へのどんな追加影響もこのようにして許容されていません。 「透明」と「偏在」要件、したがって、また、[RTP-REQ、セクション2.1]は少しも変更なしで0バイトのRTP圧縮に適用されます。

3.2.  Supported Headers and Kinds of RTP Streams

3.2. 支持されたヘッダーと種類のRTPの流れ

   The 0-byte RTP compression scheme in general imposes the same
   requirements on supported headers and RTP streams as regular ROHC RTP
   [RTP-REQ, section 2.2].  However, there are some aspects regarding
   the "Genericity" and IPSEC requirements that should be noted.

一般に、0バイトのRTP圧縮技術は通常のROHC RTP[RTP-REQ、セクション2.2]として支持されたヘッダーとRTPの流れに同じ要件を課します。 しかしながら、注意されるべきである"Genericity"とIPSEC要件に関していくつかの局面があります。

   The "Genericity" requirement of [RTP-REQ] states that compression of
   headers of arbitrary RTP streams must be supported, and this is also
   true for the 0-byte compression scheme to the extent that it is not
   allowed to assume certain RTP behavior.  However, as also stated in
   [RTP-REQ], this does not preclude optimizations for certain media
   types where the traffic pattern is known.  For 0-byte RTP, this means
   that the scheme must be able to handle arbitrary RTP streams in order
   to fulfill the requirements of section 3.1.  However, due to the
   typical characteristics of 0-byte compression, by requiring a traffic
   pattern that suits the link over which it is implemented to be able
   to compress down to 0-byte headers, it becomes optimized for
   applications with link-suited traffic patterns.  For traffic that
   does not comply with the link properties, the scheme must
   automatically and immediately fall back to non-0-byte RTP compression
   and must not have any impact on the packet stream.

[RTP-REQ]の"Genericity"要件は任意のRTPの流れのヘッダーの圧縮を支持しなければならなくて、0バイトの圧縮技術に、また、これもあるRTPの振舞いを仮定できないという範囲に誠実であると述べます。 しかしながら、また、[RTP-REQ]に述べられているように、これはトラフィック・パターンが知られているあるメディアタイプのために最適化を排除しません。 0バイトのRTPに関しては、これは、計画がセクション3.1の要件を実現させるために任意のRTPの流れを扱うことができなければならないことを意味します。 しかしながら、0バイトのヘッダーまで圧縮するそれが実行されるリンクに合うトラフィック・パターンができるのを必要とするのによる0バイトの圧縮の代表的な特徴のため、それはアプリケーションのためにリンクに合っているトラフィック・パターンで最適化されるようになります。 リンクの特性に従わない交通のために、計画は、自動的ですぐに、非0のバイトRTP圧縮へ後ろへ下がらなければならなくて、パケットの流れにどんな影響力も持ってはいけません。

   Regarding IPSEC, it should be noted that 0-byte compression cannot be
   achieved if parts of the original headers are encrypted or carry
   randomly changing fields.  IPSEC and 0-byte RTP header compression
   therefore do not go well together.  If IPSEC is used and prevents 0-
   byte compression, the scheme must fall back to a less efficient
   compression that can handle all present header fields.  Of course,
   this applies not only to IPSEC but to all cases where headers cannot
   be compressed down to 0-byte.

IPSECに関して、それは、手当たりしだいに職業を替えながら、注意されて、オリジナルのヘッダーの一部がコード化されているならその0バイトの圧縮を達成できないということであるか運ばれるべきです。 したがって、IPSECと0バイトのRTPヘッダー圧縮は一緒にうまく行きません。 IPSECが使用されていて、圧縮、計画が防がなければならない0バイトを防ぐなら、すべての現在のヘッダーフィールドを扱うことができるそれほど効率的でない圧縮へ後ろへ下がってください。 もちろん、これはIPSECに適用するだけではなく、ヘッダーを0バイトまで圧縮できないすべてのケースにも適用されます。

Jonsson                      Informational                      [Page 3]

RFC 3243        Reqs and Assumptions for 0-byte ROHC RTP      April 2002

0バイトのROHC RTP2002年4月のためのイェンソン情報[3ページ]のRFC3243Reqsと仮定

3.3.  Performance Issues

3.3. パフォーマンス問題

   All the performance requirements of [RTP-REQ] also apply to 0-byte
   RTP header compression, with the following additions and exceptions:

また、[RTP-REQ]のすべての性能要件が0バイトのRTPヘッダー圧縮に以下の追加と例外で適用されます:

   -  Performance/Spectral Efficiency: For packet streams with traffic
      patterns that match the characteristics of the link over which 0-
      byte header compression is implemented, the performance should be
      such that 0-byte header packets are generated during normal
      operation, most of the time.  0-byte headers would then replace
      most of the 1-octet headers used by regular ROHC RTP [ROHC].

- パフォーマンス/スペクトル効率: リンクの特性にどの0バイトの上合っているトラフィック・パターンがあるパケットの流れにおいて、ヘッダー圧縮は実行されて、0バイトのヘッダーパケットは性能がそのようなものであるべきであるので、通常の操作の間発生します、たいてい。 そして、0バイトのヘッダーは通常のROHC RTP[ROHC]でヘッダーが使用した1八重奏の大部分を取り替えるでしょう。

      Justification: Spectrum efficiency is a primary goal.  Studies
      have shown that for certain applications and link technologies,
      even a single octet of header may result in a significant decrease
      in spectrum efficiency, compared to existing circuit switched
      solutions.

正当化: スペクトル効率は第一の目標です。 研究は、あるアプリケーションとリンク技術のために、ヘッダーのただ一つの八重奏さえスペクトル効率のかなりの減少をもたらすかもしれないのを示しました、既存のサーキット切り換えられた解決策と比べて。

   -  Header Compression Coexistence: The scheme must fit into the ROHC
      framework together with other ROHC profiles.

- ヘッダー圧縮共存: 計画は他のROHCプロフィールと共にROHC枠組みに収まらなければなりません。

      Justification: Implementation simplicity is an important issue and
      the 0-byte RTP compression scheme should therefore have as much as
      possible in common with the regular IP/UDP/RTP profile.

正当化: 実現の簡単さは、RTP圧縮技術がしたがって通常のIP/UDP/RTPプロフィールと共用してできるだけ持つべきである切迫した課題と0バイトです。

   -  Unidirectional links: It is of less importance that the 0-byte
      header compression scheme be able to also work over unidirectional
      links.

- 単方向はリンクされます: また、0バイトのヘッダー圧縮技術が単方向のリンクの上に働くことができるのは、より少ない重要性のそうです。

      Justification: 0-byte header compression targets links that
      typically are bi-directional.

正当化: 0バイトのヘッダー圧縮は通常双方向であることのリンクを狙います。

4.  IANA Considerations

4. IANA問題

   A protocol which meets these requirements, e.g., [LLA], will require
   the IANA to assign various numbers.  This document by itself,
   however, does not require any IANA involvement.

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

5.  Security Considerations

5. セキュリティ問題

   A protocol specified to meet these requirements, e.g., [LLA], may
   have a number of security aspects that need to be considered.  This
   document by itself, however, does not add any security risks.

これらの必要条件を満たすために指定されたプロトコル例えば、[LLA]は考えられる必要がある多くのセキュリティ局面を持っているかもしれません。 しかしながら、それ自体でこのドキュメントは少しのセキュリティ危険も加えません。

Jonsson                      Informational                      [Page 4]

RFC 3243        Reqs and Assumptions for 0-byte ROHC RTP      April 2002

0バイトのROHC RTP2002年4月のためのイェンソン情報[4ページ]のRFC3243Reqsと仮定

6.  References

6. 参照

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

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

   [ROHC]    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)", RFC 3095, July 2001.

[ROHC] ボルマンとC.とバーマイスターとC.とデーゲルマルクとM.と福島とH.とハンヌとH.とイェンソンとL-E.とHakenbergとR.とコーレンとT.とLeとK.とリュウとZ.とMartenssonとA.と宮崎とA.とSvanbroとK.とWiebkeとT.とYoshimuraとT.とH.ツェン、「体力を要しているヘッダー圧縮(ROHC)」、RFC3095、2001年7月。

   [LLA]     Jonsson, L-E. and G. Pelletier, "RObust Header Compression
             (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC
             3242, April 2002.

[LLA]イェンソン、L-E.、およびG.ペレティア、「体力を要しているヘッダー圧縮(ROHC):」 「リンクレイヤはIP/UDP/RTPのためにプロフィールを補助した」RFC3242、2002年4月。

7.  Author's Address

7. 作者のアドレス

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

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

   Phone: +46 (920) 20 21 07
   Fax: +46 (920) 20 20 99
   EMail: lars-erik.jonsson@ericsson.com

以下に電話をしてください。 +46 (920)20 21 07Fax: +46 (920) 20 20 99はメールされます: lars-erik.jonsson@ericsson.com

Jonsson                      Informational                      [Page 5]

RFC 3243        Reqs and Assumptions for 0-byte ROHC RTP      April 2002

0バイトのROHC RTP2002年4月のためのイェンソン情報[5ページ]のRFC3243Reqsと仮定

8.  Full Copyright Statement

8. 完全な著作権宣言文

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Jonsson                      Informational                      [Page 6]

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

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

ruby-position ルビの表示位置を指定する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る