RFC3409 日本語訳

3409 Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression.K. Svanbro. December 2002. (Format: TXT=25815 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                         K. Svanbro
Request for Comments: 3409                                      Ericsson
Category: Informational                                    December 2002

Svanbroがコメントのために要求するワーキンググループK.をネットワークでつないでください: 3409年のエリクソンカテゴリ: 情報の2002年12月

    Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression

強健なRTP/UDP/IPヘッダー圧縮のための下層ガイドライン

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 describes lower layer guidelines for robust header
   compression (ROHC) and the requirements ROHC puts on lower layers.
   The purpose of this document is to support the incorporation of
   robust header compression algorithms, as specified in the ROHC
   working group, into different systems such as those specified by
   Third Generation Partnership Project (3GPP), 3GPP Project 2 (3GPP2),
   European Technical Standards Institute (ETSI), etc.  This document
   covers only lower layer guidelines for compression of RTP/UDP/IP and
   UDP/IP headers as specified in [RFC3095].  Both general guidelines
   and guidelines specific for cellular systems are discussed in this
   document.

このドキュメントは体力を要しているヘッダー圧縮(ROHC)のための下層ガイドラインとROHCが下層に置く要件について説明します。 このドキュメントの目的は強健なヘッダー圧縮アルゴリズムの編入を支持することです、ROHCワーキンググループで指定されるように、Third Generation Partnership Projectによって指定されたもの(3GPP)、3GPP Project2(3GPP2)、ヨーロッパのTechnical Standards Institute(ETSI)などの異系統に このドキュメントは[RFC3095]の指定されるとしてのRTP/UDP/IPとUDP/IPヘッダーの圧縮のための下層ガイドラインだけをカバーしています。 本書では一般的ガイドラインとセルラ方式に、特定のガイドラインの両方について議論します。

Table of Contents

目次

   1.  Introduction.................................................. 2
   2.  General guidelines............................................ 2
         2.1.  Error detection....................................... 2
         2.2.  Inferred header field information..................... 3
         2.3.  Handling of header size variation..................... 3
         2.4.  Negotiation of header compression parameters.......... 5
         2.5.  Demultiplexing of flows onto logical channels......... 5
         2.6.  Packet type identification............................ 5
         2.7.  Packet duplication.................................... 6
         2.8.  Packet reordering..................................... 6
         2.9.  Feedback packets...................................... 6
   3.  Cellular system specific guidelines........................... 7
         3.1.  Handover procedures................................... 7
         3.2.  Unequal error detection (UED)......................... 8
         3.3.  Unequal error protection (UEP)........................ 9

1. 序論… 2 2. 一般的ガイドライン… 2 2.1. 誤り検出… 2 2.2. ヘッダーフィールド情報を推論します… 3 2.3. ヘッダーサイズ変化の取り扱い… 3 2.4. ヘッダー圧縮パラメタの交渉… 5 2.5. 論理チャネルへの流れの逆多重化… 5 2.6. パケットタイプ確認… 5 2.7. パケット複製… 6 2.8. パケット再命令… 6 2.9. フィードバックパケット… 6 3. セルラ方式特別な基準… 7 3.1. 引き渡し手順… 7 3.2. 不平等な誤り検出(UED)… 8 3.3. 不平等な誤り保護(UEP)… 9

Svanbro                      Informational                      [Page 1]

RFC 3409         Lower Layer Guidelines for Robust HC      December 2002

Svanbroの情報[1ページ]のRFC3409は2002年12月に強健なHCのための層のガイドラインを下ろします。

   4.  IANA Considerations........................................... 9
   5.  Security Considerations....................................... 9
   6.  References.................................................... 9
   7.  Author's Address..............................................10
   8.  Full Copyright Statement......................................11

4. IANA問題… 9 5. セキュリティ問題… 9 6. 参照… 9 7. 作者のアドレス…10 8. 完全な著作権宣言文…11

1.  Introduction

1. 序論

   Almost all header compression algorithms [RFC1144, RFC2507, RFC2508]
   rely on some functionality from the underlying link layer.  Headers
   (compressed or not) are expected to be delivered without any residual
   bit errors.  IP length fields are inferred from link layer length
   fields.  Packet type identification may be separated from the header
   compression scheme and performed at the underlying link layer.
   [RFC2509], for example, elaborates on how to incorporate IP header
   compression [RFC2507] in PPP [RFC1661].

ほとんどすべてのヘッダー圧縮アルゴリズム[RFC1144、RFC2507、RFC2508]が基本的なリンクレイヤからの何らかの機能性を当てにします。 少しも残りの噛み付いている誤りなしでヘッダー(圧縮された)が渡されると予想されます。 IP長さの分野はリンクレイヤ長さの分野から推論されます。 パケットタイプ確認は、ヘッダー圧縮技術と切り離されて、基本的なリンクレイヤで実行されるかもしれません。 例えば、[RFC2509]はどう、IPヘッダー圧縮[RFC2507]をPPP[RFC1661]に取り入れるかを詳しく説明します。

   It is important to be aware of such assumptions on required
   functionality from underlying layers when incorporating a header
   compression scheme into a system.  The functionality required by a
   specific header compression scheme from lower layers may also be
   needed if incorporation of a header compression scheme is to be
   prepared without knowing the exact details of the final scheme.

ヘッダー圧縮技術をシステムに組み入れるとき、下位層からの必要な機能性でそのような仮定を意識しているのは重要です。 また、特定のヘッダー圧縮技術によって下層から必要とされた機能性がヘッダー圧縮技術の編入が最終的な計画の正確な詳細を知らないで準備されることであるなら必要であるかもしれません。

   This document describes lower layer guidelines for robust RTP/UDP/IP
   header compression [RFC3095] as specified by the ROHC working group.
   [RFC3095] will from this point be referenced to as ROHC.  These
   guidelines should simplify incorporation of the robust header
   compression algorithms into cellular systems like those standardized
   by 3GPP, 3GPP2, ETSI, etc, and also into specific link layer
   protocols such as PPP.  The document should also enable preparation
   of this incorporation without requiring detailed knowledge about the
   final header compression scheme.  Relevant standardization groups
   standardizing link layers should, aided by this document, include
   required functionality in "their" link layers to support robust
   header compression.

このドキュメントはROHCワーキンググループによる指定されるとしての強健なRTP/UDP/IPヘッダー圧縮[RFC3095]のために下層ガイドラインについて説明します。 参照をつけられて、これから指すためにROHCとして望んでいます[RFC3095]。 ものが3GPP、3GPP2、ETSIなどと、特定のリンクレイヤの中にもPPPなどのプロトコルを標準化したようにこれらのガイドラインは強健なヘッダー圧縮アルゴリズムの編入をセルラ方式に簡素化するべきです。 また、最終的なヘッダー圧縮技術に関する詳細な知識を必要としないで、ドキュメントはこの編入の準備を可能にするはずです。 このドキュメントによって支援されて、リンクレイヤを標準化する関連標準化グループは、体力を要しているヘッダー圧縮を支持するために「their」のリンクレイヤに必要な機能性を含むべきです。

   Hence, this document clarifies the requirements ROHC put on lower
   layers, while the requirements on ROHC may be found in [RFC3096].

したがって、このドキュメントはROHCが下層に置く要件をはっきりさせます、ROHCに関する要件が[RFC3096]で見つけられるかもしれませんが。

2.  General guidelines

2. 一般的ガイドライン

2.1.  Error detection

2.1. 誤り検出

   All current header compression schemes [RFC1144, RFC2507, RFC2508]
   rely on lower layers to detect errors in (compressed) headers.  This
   is usually done with link layer checksums covering at least the

すべての現在のヘッダー圧縮技術[RFC1144、RFC2507、RFC2508]が、(圧縮される)のヘッダーに誤りを検出するために下層を当てにします。 通常、少なくともリンクレイヤチェックサム覆いでこれをします。

Svanbro                      Informational                      [Page 2]

RFC 3409         Lower Layer Guidelines for Robust HC      December 2002

Svanbroの情報[2ページ]のRFC3409は2002年12月に強健なHCのための層のガイドラインを下ろします。

   compressed header.  However, any error detecting mechanism may fail
   to detect some bit errors, which are usually called residual bit
   errors.

圧縮されたヘッダー。 しかしながら、どんな誤り検出メカニズムもいくつかの噛み付いている誤りを検出しないかもしれません。(通常、誤りは残りの噛み付いている誤りと呼ばれます)。

   As for non-compressed IP packets, lower layers must provide similar
   error detection, at least for ROHC headers.  ROHC has been designed
   not to increase the residual bit error rate (for reasonable residual
   error rates) compared to the case when no header compression is used.
   Headers passed up to the header decompressor should, however, have a
   residual bit error probability close to zero.

非圧縮されたIPパケットに関して、下層は同様の誤り検出を少なくともROHCヘッダーに供給しなければなりません。 ROHCは、どんなヘッダー圧縮も使用されていないとき、ケースと比べて、残りのビット誤り率(妥当な見逃し誤りレートのための)を増加させないように設計されています。 しかしながら、ヘッダー減圧装置まで渡されたヘッダーはゼロの近くに残りの噛み付いているエラー確率を持つべきです。

   A ROHC decompressor might make use of packets with erroneous headers,
   even if they must be discarded.  It is therefore recommended that
   such invalid packets are passed up to the decompressor instead of
   being discarded by lower layers, but the packet must then be
   accompanied with an error indication.

彼らを捨てなければならなくても、ROHC減圧装置は誤ったヘッダーがあるパケットを利用するかもしれません。 したがって、そのような無効のパケットが下層によって捨てられることの代わりに減圧装置まで通過されますが、次に、誤り表示でパケットに伴わなければならないのはお勧めです。

2.2.  Inferred header field information

2.2. 推論されたヘッダーフィールド情報

   Some fields of the RTP/UDP/IP headers may be classified as inferred,
   that is their values are to be inferred from other values or from an
   underlying link layer.  A ROHC decompressor requires that at least
   the following information can be inferred from any underlying link
   layer:

RTP/UDP/IPヘッダーのいくつかの分野が推論されるように分類されるかもしれません、すなわち、彼らの値は他の値、または、基本的なリンクレイヤから推論されることです。 ROHC減圧装置は、どんな基本的なリンクレイヤからも少なくとも以下の情報を推論できるのを必要とします:

   Packet Length (IPv4) / Payload Length (IPv6)

パケット長(IPv4)/ペイロード長(IPv6)

     The received packet (with compressed header) length.

容認されたパケット(圧縮されたヘッダーがある)の長さ。

   Length (UDP)

長さ(UDP)

     This field is redundant with the Packet Length (IPv4) or the
     Payload Length (IPv6) field.

この分野はPacket Length(IPv4)か有効搭載量Length(IPv6)分野で余分です。

   In summary, all these fields relate to the length of the packet the
   compressed header is included in.  These fields may thus be inferred
   by the decompressor if one packet length value is signaled from the
   link layer to the decompressor on a per packet basis.  This packet
   length value should be the length of the received packet including
   the (compressed) header.

概要では、これらのすべての分野が圧縮されたヘッダーが含まれているパケットの長さに関連します。 その結果、あるパケット長値がパケット基礎あたりのaでリンクレイヤから減圧装置まで合図されるなら、これらの分野は減圧装置によって推論されるかもしれません。 このパケット長値は(圧縮される)のヘッダーを含む容認されたパケットの長さであるべきです。

2.3.  Handling of header size variations

2.3. ヘッダーサイズ変化の取り扱い

   It is desirable for many cellular link layer technologies that bit
   rate variations and thus packet size variations are minimized.
   However, there will always be some variation in compressed header
   sizes since there is a trade-off between header size variations and
   compression efficiency, and also due to events in the header flow and

多くのセルリンクレイヤ技術において、ビット伝送速度変化とその結果パケットサイズ変化が最小にされるのは、望ましいです。 そしてしかしながら、ヘッダーサイズ変化と圧縮効率と、ヘッダー流動における出来事のためもトレードオフがあるので圧縮されたヘッダーサイズの何らかの変化がいつもある。

Svanbro                      Informational                      [Page 3]

RFC 3409         Lower Layer Guidelines for Robust HC      December 2002

Svanbroの情報[3ページ]のRFC3409は2002年12月に強健なHCのための層のガイドラインを下ろします。

   on the channel.  Variations in header sizes cause variations in
   packet sizes depending on variations of payload size.  The following
   will only treat header size variations caused by ROHC and not packet
   size variations due to variations of payload size.

チャンネルに関して。 ヘッダーサイズの変化はペイロードサイズの変化に依存するパケットサイズの変化を引き起こします。 以下はペイロードサイズの変化のためパケットサイズ変化ではなく、ROHCによって引き起こされたヘッダーサイズ変化を扱うだけでしょう。

   The link layer must in some manner support varying header sizes from
   40 bytes (full RTP/UDP/IPv4 header) or 60 bytes (full RTP/UDP/IPv6)
   down to 1 byte for the minimal compressed header.  It is likely that
   the small compressed headers dominate the flow of headers, and that
   the largest headers are sent rarely, e.g., only a few times in the
   initialization phase of the header compression scheme.

リンクレイヤは、最小量の圧縮されたヘッダーのために40バイト(完全なRTP/UDP/IPv4ヘッダー)か60バイト(完全なRTP/UDP/IPv6)最小1バイトからヘッダーサイズを変えるのを何らかの方法で支持しなければなりません。 小さい圧縮されたヘッダーはヘッダーの流れを支配しています、そして、最も大きいヘッダーはめったに送られそうにはありません、例えば、ヘッダー圧縮技術の初期設定段階におけるほんの数回。

   Header size variations and thus packet size variations depend on
   numerous factors.  Unpredictable changes in the RTP, UDP or IP
   headers may cause compressed headers to momentarily increase in size,
   and header sizes may depend on packet loss rate at lower layers.
   Header size distributions depend also on the mode ROHC operates in.
   However, for e.g., a voice application, carried by RTP/UDP/IPv4, with
   a constant speech frame size and silence suppression, the following
   basic header size changes may be considered as typical:

ヘッダーサイズ変化とその結果パケットサイズ変化は多数の要素に依存します。 圧縮されたヘッダーはしばらくRTP、UDPまたはIPヘッダーにおける予測できない変化で大きくなるかもしれません、そして、ヘッダーサイズは下層でパケット損失率に依存するかもしれません。 また、ヘッダーサイズ配はROHCが作動するモードに依存します。 しかしながら、例えば、音声アプリケーションのために、一定のスピーチフレーム・サイズと沈黙抑圧でRTP/UDP/IPv4によって運ばれます、以下の基本的なヘッダーサイズ変化は典型的であるとみなされるかもしれません:

   In the very beginning of the speech session, the ROHC scheme is
   initialized by sending full headers called IR/DYN.  These are the
   largest headers, with sizes depending basically on the IP-version.
   For IPv4 the size is approximately 40 bytes, and for IPv6
   approximately 60 bytes.  The IR/DYN headers are used typically during
   one round trip time, possible interleaved with compressed headers.
   After that, usually only compressed headers are sent.  Compressed
   headers may vary in size from 1 byte up to several bytes.  The
   smallest compressed headers are used when there is no unpredictable
   changes in header fields, typically during a talk spurt.  In the
   beginning of a talk spurt, compressed header sizes may increase by
   one or a few bytes momentarily.  Apart from increases due to new talk
   spurts, compressed headers may increase in size momentarily due to
   unpredictable changes in header fields.

非常にスピーチセッションについて始まることでは、ROHC計画はIR/DYNと呼ばれる送付の完全なヘッダーによって初期化されます。 これらはサイズを基本的にIP-バージョンに依存している最も大きいヘッダーです。 IPv4に関しては、サイズはおよそ60バイトおよそ40バイト、およびIPv6のためのものです。 IR/DYNヘッダーは可能な丸い1旅行時間圧縮されたヘッダーと共にはさみ込まれた状態で通常使用されます。 その後に、通常唯一の圧縮されたヘッダーを送ります。 圧縮されたヘッダーは数バイトまでの1バイトから大小の差があるかもしれません。 どんな予測できない変化もヘッダーフィールドと、通常話のスパートの間ないとき、最も小さい圧縮されたヘッダーは使用されています。 しばらく、初めに、話のスパートでは、圧縮されたヘッダーサイズは1か数バイト増加するかもしれません。 新しい話のスパートによる増加は別として、圧縮されたヘッダーはヘッダーフィールドにおける予測できない変化のためしばらく大きくなるかもしれません。

   ROHC provides some means to limit the amount of produced header
   sizes.  In some cases a larger header than needed may be used to
   limit the number of header sizes used.  Padding octets may also be
   used to fill up to a desired size.  Chapter 6.3 (Implementation
   parameters) in [RFC3095] provides optional implementation parameters
   that make it possible to mandate how a ROHC implementation should
   operate, for instance to mandate how many header sizes that may be
   used.

ROHCは生産されたヘッダーサイズの量を制限するいくつかの手段を提供します。 いくつかの場合、必要とされるより大きいヘッダーは、サイズが使用したヘッダーの数を制限するのに使用されるかもしれません。 また、八重奏を水増しするのは、必要なサイズまでいっぱいになるのに使用されるかもしれません。 [RFC3095]の第6.3章(実現パラメタ)は例えば、ROHC実現が使用されるかもしれないいくつのヘッダーサイズを強制するかためにどう作動するべきであるかを強制するのを可能にする任意の実現パラメタを提供します。

Svanbro                      Informational                      [Page 4]

RFC 3409         Lower Layer Guidelines for Robust HC      December 2002

Svanbroの情報[4ページ]のRFC3409は2002年12月に強健なHCのための層のガイドラインを下ろします。

2.4.  Negotiation of header compression parameters

2.4. ヘッダー圧縮パラメタの交渉

   ROHC has some parameters that need to be configured in an initial
   setup phase.  Which header compression profiles are allowed may have
   to be determined and also what kind of context identification (CID)
   mechanism to use.

ROHCには、初期のセットアップフェーズで構成される必要があるいくつかのパラメタがあります。 プロフィールが許容されている圧縮がそうするどのヘッダーが断固としなければならないか、そして、また、どういう文脈識別(CID)メカニズムを使用しますか?

   The lower layers supporting ROHC should thus include mechanisms for
   negotiation of header compression parameters such as CID usage and
   header compression profile support.  In certain environments, it
   might also be desirable to have mechanisms for re-negotiation of
   these parameters.

その結果、ROHCを支持する下層はCID用法やヘッダー圧縮プロフィールサポートなどのヘッダー圧縮パラメタの交渉のためのメカニズムを含むべきです。 また、ある環境で、これらのパラメタの再交渉のためのメカニズムを持っているのも望ましいかもしれません。

   The negotiation must also make sure that compressor and decompressor
   use exactly the same profile, i.e. that the set of profiles available
   after negotiation must not include two profile identifiers with the
   same 8-bit LSB value.

また、交渉は同じ8ビットのLSB値がある2つのプロフィール識別子を含んではいけなかった後に確実にそのコンプレッサーとすなわち、ちょうど同じくらいが輪郭を描く減圧装置使用、それをプロフィールの利用可能なセットにしなければなりません。

   For unidirectional links, this configuration might have to be
   performed out-of-band or a priori, and similar methods could of
   course also be used for bi-directional links if direct negotiation is
   not possible.

単方向のリンクに関しては、この構成がバンドの外で実行されなければならないかもしれない、また、さもなければ、直談が可能でないなら、先験的で、同様の方法は双方向のリンクにもちろん使用されるかもしれません。

2.5.  Demultiplexing of flows onto logical channels

2.5. 論理チャネルへの流れの逆多重化

   In some cellular technologies flows are demultiplexed onto radio
   bearers suitable to the particular flows, i.e., onto logically
   separated channels.  For instance, real-time flows such as voice and
   video may be carried on logically separated bearers.  It is
   recommended that this kind of demultiplexing is done in the lower
   layers supporting robust header compression.  By doing so, the need
   for context identification in the header compression scheme is
   reduced.  If there is a one to one mapping between flow and logical
   channel, there is no need at all for context identification at the
   header compression level.

いくつかの携帯電話技術で、流れはすなわち、特定の流れに適したラジオ運搬人、論理的に切り離されたチャンネルに反多重送信されます。 例えば、声やビデオなどのリアルタイムの流れは論理的に切り離された運搬人の上で運ばれるかもしれません。 体力を要しているヘッダー圧縮を支持する下層でこの種類の逆多重化をするのはお勧めです。 そうすることによって、ヘッダー圧縮技術における文脈識別の必要性は減少します。 流れと論理チャネルの間には、1〜1つのマッピングがあれば、必要は文脈識別のために全くヘッダー圧縮レベルに全くありません。

2.6.  Packet type identification

2.6. パケットタイプ確認

   Header compression schemes like [RFC2507, RFC2508] have relied on the
   underlying link layer to identify different kinds of headers by means
   of packet type identifiers on link layers.  This kind of mechanism is
   not necessarily needed for ROHC since a ROHC packet type identifier
   is included in all compressed ROHC headers.  Only if ROHC packets are
   to be mixed with other packets, such as packets compressed by other
   header compression schemes, must the link layer provide a packet type
   identifier.  In such cases, or if ROHC is used on top of link layers
   already providing packet type identification, one (1) packet type
   identifier must be reserved for identification of ROHC packets. Thus,

[RFC2507、RFC2508]がリンクレイヤに関するパケットタイプ識別子によって異種のヘッダーを特定するために基本的なリンクレイヤを当てにしたようにヘッダー圧縮は計画されます。 ROHCパケットタイプ識別子がすべての圧縮されたROHCヘッダーに含まれているので、この種類のメカニズムが必ずROHCに必要であるというわけではありません。 圧縮は計画されます、と単にROHCパケットが他のパケットに混ぜられるつもりである他のヘッダーによって圧縮されたパケットなどのようにリンクレイヤがパケットタイプ識別子を前提としなければなりません。 そのような場合かROHCが既にパケットタイプ確認を提供しながらリンクレイヤの上で使用されるなら、ROHCパケットの識別のために1(1)パケットタイプ識別子を予約しなければなりません。 このようにして

Svanbro                      Informational                      [Page 5]

RFC 3409         Lower Layer Guidelines for Robust HC      December 2002

Svanbroの情報[5ページ]のRFC3409は2002年12月に強健なHCのための層のガイドラインを下ろします。

   only one ROHC packet type is needed to mix ROHC and e.g., RFC 2507
   flows, or to support ROHC on links where packet type identifiers are
   already present.

1つのROHCパケットタイプだけが、ROHCと例えばRFC2507流れるのを混ぜるか、またはパケットタイプ識別子が既に存在しているリンクの上のROHCを支持するのに必要です。

2.7.  Packet duplication

2.7. パケット重複

   Exact duplications of one and the same packet may waste transmission
   resources and is in contradiction to compression.  Even so, packet
   duplication may occur for various reasons.  Packet duplication may
   also occur in different places along the path for a packet.

全く同じパケットの正確な複製は、トランスミッションリソースを浪費するかもしれなくて、圧縮に反しています。 たとえそうだとしても、パケット重複は様々な理由で起こるかもしれません。 また、パケット重複はパケットのための経路に沿った異なった場所に起こるかもしれません。

   ROHC can handle packet duplication before the compressor but such
   packet duplications should be avoided for optimal compression
   efficiency.  For correct ROHC operation, lower layers are not allowed
   to duplicate packets on the ROHC compressor-decompressor path.

ROHCはコンプレッサーの前でパケット重複を扱うことができますが、そのようなパケット重複は最適の圧縮効率のために避けられるべきです。 正しいROHC操作において、下層はROHCコンプレッサー減圧装置経路にパケットをコピーできません。

2.8.  Packet reordering

2.8. パケット再命令

   Lower layers between compressor and decompressor are assumed not to
   reorder packets, i.e., the decompressor must receive packets in the
   same order as the compressor sends them.  ROHC handles, however,
   reordering before the compression point.  That is, there is no
   assumption that the compressor will only receive packets in sequence.

コンプレッサーと減圧装置の間の下層はどんな追加注文パケットにも想定されません、すなわち、コンプレッサーがそれらを送るとき、減圧装置が同次でパケットを受けなければなりません。 しかしながら、ROHCは圧密点の前での再命令を扱います。 すなわち、コンプレッサーが連続してパケットを受けるだけであるという仮定が全くありません。

2.9.  Feedback packets

2.9. フィードバックパケット

   ROHC may operate in three different modes; Unidirectional mode (U-
   mode), bidirectional optimistic mode (O-mode) and bidirectional
   reliable mode (R-mode).  A brief description of the modes can be
   found in chapter 4.4 of [RFC3095].

ROHCは3つの異なったモードで作動するかもしれません。 単方向のモード(Uモード)、双方向の楽観的なモード(O-モード)、および双方向の信頼できるモード(R-モード)。 [RFC3095]の第4.4章でモードの簡単な説明を見つけることができます。

   In U-mode it is not necessary to send any feedback from the
   decompressor to the compressor.  O-mode and R-mode requires however
   that feedback messages from the decompressor to the compressor be
   sent.  Feedback messages consist of small ROHC internal packets
   without any application payload.  It is possible in ROHC to piggy-
   back feedback packets onto regular packets with ROHC compressed
   headers and payload, if there is ROHC type of compression in both the
   forward and reverse direction.  However, this piggy-backing may not
   be desired or possible in some cases.

U-モードで、どんなフィードバックも減圧装置からコンプレッサーに送るのは必要ではありません。 しかしながら、O-モードとR-モードは、減圧装置からコンプレッサーまでのフィードバックメッセージが送られるのを必要とします。 フィードバックメッセージは少しもアプリケーションペイロードなしで小さいROHC内部のパケットから成ります。 パケットがROHCがあるレギュラーのパケットにヘッダーとペイロードを圧縮したのは、ROHCで子豚の逆フィードバックに可能です、両方の前進の、そして、反対の方向への圧縮のROHCタイプがあれば。 しかしながら、いくつかの場合、この便乗は、必要であるか、または可能でないかもしれません。

   To support ROHC O-mode or R-mode operation, lower layers must provide
   transport of feedback packets from decompressor to compressor.  If
   piggybacking of feedback packets is not used, lower layers must be
   able to handle feedback as small stand-alone packets.  For optimal
   compression efficiency, feedback packets from the decompressor should
   be delivered as soon as possible to the compressor.

ROHC O-モードかR-モード操作を支持するために、下層はフィードバックパケットの減圧装置からコンプレッサーまでの輸送を提供しなければなりません。 フィードバックパケットの便乗が使用されていないなら、下層は小さいスタンドアロンのパケットとしてフィードバックを扱うことができなければなりません。 最適の圧縮効率において、できるだけ早く、減圧装置からのフィードバックパケットをコンプレッサーに渡すべきです。

Svanbro                      Informational                      [Page 6]

RFC 3409         Lower Layer Guidelines for Robust HC      December 2002

Svanbroの情報[6ページ]のRFC3409は2002年12月に強健なHCのための層のガイドラインを下ろします。

3.  Cellular system specific guidelines

3. セルラ方式特別な基準

   An important group of link layer technologies where robust header
   compression will be needed are future cellular systems, which may
   have a very large number of users in some years.  The need for header
   compression is large in these kinds of systems to achieve spectrum
   efficiency.  Hence, it is important that future cellular systems can
   efficiently incorporate the robust header compression scheme.

体力を要しているヘッダー圧縮が必要であるリンクレイヤ技術の重要なグループは将来のセルラ方式です。(そこには、数年後に、非常に多くのユーザがいるかもしれません)。 ヘッダー圧縮の必要性はスペクトル効率を達成するこれらの種類のシステムで大きいです。 したがって、将来のセルラ方式が効率的に強健なヘッダー圧縮技術を取り入れることができるのは、重要です。

3.1.  Handover procedures

3.1. 引き渡し手順

   One cellular specific property that may affect header compression is
   mobility and thus, handover (i.e., change of serving base station or
   radio network controller).

ヘッダー圧縮に影響するかもしれない1つのセル特定の性質は、移動性とその結果、引き渡しです(すなわち、基地局かラジオネットワーク制御装置に役立つ変化)。

   The main characteristics of handovers relevant for robust header
   compression are: the length of the longest packet loss event due to
   handover (i.e., the number of consecutive packet losses), and
   relocation of header compression context when necessary.

体力を要しているヘッダー圧縮において、関連している身柄の引き渡しの主な特性は以下の通りです。 引き渡し(すなわち、連続したパケット損失の数)による最も長いパケット損失出来事の長さ、および必要でありヘッダー圧縮文脈の再配置。

   Depending on the location of the header compressor/decompressor in
   the radio access network and the type of handover, handover may or
   may not cause disruptions or packet loss events in the (compressed)
   header flow relevant for the header compression scheme.  For
   instance, if soft handover is used and if the header
   compressor/decompressor reside above the combining point for soft
   handover, there will be no extra packet losses visible to the
   decompressor due to handover.  In hard handovers, where packet loss
   events due to handover is introduced, the length of the longest
   consecutive packet loss is most relevant and thus should be
   minimized.

引き渡しのラジオアクセスネットワークとタイプでヘッダーコンプレッサー/減圧装置の位置によって、引き渡しはヘッダー圧縮技術において、関連している(圧縮される)のヘッダー流動における出来事を分裂かパケット損失に引き起こすかもしれません。 例えば、ソフトハンドオーバが使用されていて、ヘッダーコンプレッサー/減圧装置がソフトハンドオーバのための結合ポイントより上であると、引き渡しのために減圧装置に目に見えるどんな余分なパケット損失もないでしょう。困難な身柄の引き渡しでは、最も長い連続したパケット損失の長さは、引き渡しへのパケット損失イベント支払われるべきものを導入するところで最も関連していて、その結果、最小にされるべきです。

   To maintain efficient ROHC operation, it should be ensured that
   handover events do not cause significant long events of consecutive
   packet loss.  The term "significant" in this context relates to the
   kind of loss tolerable for the carried real-time application.

効率的なROHC操作を維持するために、引き渡し出来事が連続したパケット損失の重要な長い出来事を引き起こさないのが確実にされるべきです。 「重要である」という用語はこのような関係においては運ばれたリアルタイムのアプリケーションにおいて、許容できる損失の種類に関連します。

   If hard handovers are performed, which may cause significant long
   events of consecutive packet loss, the radio access network should
   notify the compressor when such a handover has started and completed.
   The compressor could then be implemented to take proper actions and
   prevent consequences from such long loss events.

そのような引き渡しが通知したとき、始められて、完成されて、ラジオアクセスネットワークは、困難な身柄の引き渡しが実行されるなら、どれが連続したパケット損失の重要な長い出来事を引き起こすかもしれないようにコンプレッサーに通知するべきです。 そして、そのような長い損失出来事から適切な行動を取って、結果を防ぐためにコンプレッサーを実行できました。

   Cellular systems supporting robust header compression may have
   internal mechanisms for transferring the header compression context
   between nodes where contexts may reside, at or before handover.  If
   no such mechanism for transferring header compression context between
   nodes is available, the contexts may be resynchronized by the header

体力を要しているヘッダー圧縮を支持するセルラ方式はノードに間文脈が引き渡しにおいて引き渡しの前にあるかもしれないヘッダー圧縮文脈を移すための内部のメカニズムを持っているかもしれません。ヘッダー圧縮文脈をノードの間に移すためのそのような何かメカニズムが利用可能でないなら、ヘッダーは文脈を再連動させるかもしれません。

Svanbro                      Informational                      [Page 7]

RFC 3409         Lower Layer Guidelines for Robust HC      December 2002

Svanbroの情報[7ページ]のRFC3409は2002年12月に強健なHCのための層のガイドラインを下ろします。

   compression scheme itself by means of a context refresh.  The header
   compressor will then perform a new header compression initialization,
   e.g., by sending full headers.  This will, however, introduce an
   increase in the average header size dependent on how often a transfer
   of context is needed.  To reinitialize the context in such cases, the
   lower layers must indicate to the header compressor when a handover
   has occurred, so that it knows when to refresh the context.  Chapter
   6.3 (Implementation parameters) in [RFC3095] provides optional
   implementation parameters that make it possible to trigger e.g., a
   complete context refresh.

文脈による圧縮技術自体はリフレッシュします。 そして、ヘッダーコンプレッサーは、例えば、完全なヘッダーを送ることによって、新しいヘッダー圧縮初期化を実行するでしょう。 しかしながら、これは文脈の転送がどれくらいの頻度で必要であるか依存していた状態で平均したヘッダーサイズの増加を導入するでしょう。 そのような場合文脈を再初期化するために、下層は、引き渡しがいつ起こったかをヘッダーコンプレッサーに示さなければなりません、いつ文脈をリフレッシュするかを知るように。 [RFC3095]の第6.3章(実現パラメタ)はそれを引き金となるのにおいて可能にする任意の実現パラメタを提供します、例えば、完全な関係がリフレッシュします。

3.2.  Unequal error detection (UED)

3.2. 不平等な誤り検出(UED)

   Section 3.1 states that ROHC requires error detection from lower
   layers for at least the compressed header.  However, some cellular
   technologies may differentiate the amount of error detection for
   different parts of a packet.  For instance, it could be possible to
   have a stronger error detection for the header part of a packet, if
   the application payload part of the packet is less sensitive to
   errors, e.g., some cellular types of speech codes.

セクション3.1は、ROHCが少なくとも圧縮されたヘッダーのために下層から誤り検出を必要とすると述べます。 しかしながら、いくつかの携帯電話技術がパケットの異なった一部のための誤り検出の量を微分するかもしれません。 例えば、パケットのヘッダー一部のための、より強い誤り検出を持っているのは可能であるかもしれません、パケットのアプリケーションペイロード一部がそれほど誤りに敏感でないなら、例えば何人かの細胞型の言葉遣いの規範。

   ROHC does not require UED from lower layers, ROHC requires only an
   error detection mechanism that detects errors in at least the header
   part of the packet.  Thus there is no requirement on lower layers to
   provide separate error detection for the header and payload part of a
   packet.  However, overall performance may be increased if UED is
   used.

ROHCは下層からUEDを必要としないで、ROHCはパケットのヘッダー一部に誤りを検出する誤り検出メカニズムだけを必要とします。 したがって、パケットのヘッダーとペイロード一部のための別々の誤り検出を提供するという下層に関する要件が全くありません。 しかしながら、UEDが使用されているなら、総合的な性能は増やされるかもしれません。

   For example, if equal error detection is used in the form of one link
   layer checksum covering the entire packet including both header and
   payload part, any bit error will cause the packet to be discarded at
   the ROHC decompressor.  It is not possible to distinguish between
   errors in the header and the payload part of the packet with this
   error detection mechanism and the ROHC decompressor must assume that
   the header is damaged, even if the bit error hit the payload part of
   the packet.  If the header is assumed to be damaged, it is not
   possible to ensure correct decompression and that packet will thus be
   discarded.  If the application is such that it tolerates some errors
   in the payload, it could have been better to deliver that packet to
   the application and let the application judge whether the payload was
   usable or not.  Hence, with an unequal error detection scheme where
   it is possible to separate detection of errors in the header and
   payload part of a packet, more packets may be delivered to
   applications in some cases for the same lower layer error rates.  The
   final benefit depends of course on the cost of UED for the radio
   interface and related protocols.

例えば、ヘッダーとペイロード部分の両方を含んでいて、等しい誤り検出が全体のパケットを覆いながら1個のリンクレイヤのチェックサムの形で使用されると、どんなビット、誤りでROHC減圧装置でパケットを捨てるでしょう。 パケットのヘッダーとペイロード一部でこの誤り検出メカニズムで誤りを見分けるのが可能でなく、ROHC減圧装置は、ヘッダーが破損されていると仮定しなければなりません、噛み付いている誤りがパケットのペイロード一部を打ったとしても。 ヘッダーが破損すると思われるなら、その結果、正しい減圧とそのパケットが捨てられるのを保証するのは可能ではありません。 アプリケーションがそのようなものであるのでペイロードにおけるいくつかの誤りを許容するなら、そのパケットをアプリケーションに届けて、ペイロードが使用可能であったかどうかアプリケーションに判断させるのは、より良かったかもしれません。 したがって、不平等な誤り検出計画がパケットのヘッダーとペイロード一部での誤りの検出を切り離すのが可能であるところである場合、いくつかの場合、同じ下層誤り率のアプリケーションにより多くのパケットを届けるかもしれません。 最終的な利益はラジオインタフェースと関連するプロトコルのためにもちろんUEDの費用に依存します。

Svanbro                      Informational                      [Page 8]

RFC 3409         Lower Layer Guidelines for Robust HC      December 2002

Svanbroの情報[8ページ]のRFC3409は2002年12月に強健なHCのための層のガイドラインを下ろします。

3.3.  Unequal error protection (UEP)

3.3. 不平等な誤り保護(UEP)

   Some cellular technologies can provide different error probabilities
   for different parts of a packet, unequal error protection (UEP).  For
   instance, the lower layers may provide a stronger error protection
   for the header part of a packet compared to the payload part of the
   packet.

いくつかの携帯電話技術がパケットの異なった一部、不平等な誤り保護(UEP)に異なったエラー確率を提供できます。 例えば、パケットのペイロード一部と比べて、下層はパケットのヘッダー一部のための、より強い誤り保護を提供するかもしれません。

   ROHC does not require UEP.  UEP may be beneficial in some cases to
   reduce the error rate in ROHC headers, but only if it is possible to
   distinguish between errors in header and payload parts of a packet,
   i.e., only if unequal error detection (UED) is used.  The benefit of
   UEP depends of course on the cost of UEP for the radio interface and
   related protocols.

ROHCはUEPを必要としません。 不平等な誤り検出(UED)が使用されている場合にだけすなわち、パケットのヘッダーとペイロード一部で誤りを見分けるのが可能である場合にだけ、UEPは、いくつかの場合、ROHCヘッダーで誤り率を減少させるのに有益であるかもしれません。 UEPの利益はラジオインタフェースと関連するプロトコルのためにもちろんUEPの費用に依存します。

4.  IANA Considerations

4. IANA問題

   A protocol which follows these guidelines, e.g., [RFC3095], will
   require the IANA to assign various numbers.  This document by itself,
   however, does not require IANA involvement.

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

5.  Security Considerations

5. セキュリティ問題

   A protocol which follows these guidelines, e.g., [RFC3095], must be
   able to compress packets containing IPSEC headers according to
   [RFC3096].  There may be other security aspects to consider in such
   protocols.  This document by itself, however, does not add security
   risks.

これらのガイドラインに従うプロトコル例えば、[RFC3095]は[RFC3096]に従ってIPSECヘッダーを含むパケットを圧縮できなければなりません。 そのようなプロトコルで考える他のセキュリティ局面があるかもしれません。 しかしながら、それ自体でこのドキュメントはセキュリティ危険を加えません。

6.  References

6. 参照

   [RFC1144]   Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
               Serial Links", RFC 1144, February 1990.

1990年2月の[RFC1144]ジェーコブソン対「低速連続のリンクへのTCP/IPヘッダーを圧縮すること」でのRFC1144

   [RFC1661]   Simpson, W., Ed., "The Point-To-Point Protocol (PPP)",
               STD 51, RFC 1661, July 1994.

[RFC1661] シンプソン、W.、エド、「二地点間プロトコル(ppp)」、STD51、RFC1661、7月1994日

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

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

   [RFC2508]   Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
               Headers for Low-Speed Serial Links", RFC 2508, February
               1999.

[RFC2508]Casner、S.、およびRFC2508、1999年2月対「低速連続のリンクへのIP/UDP/RTPヘッダーを圧縮する」ジェーコブソン

   [RFC2509]   Engan, M., Casner, S. and C. Bormann, "IP Header
               Compression over PPP", RFC 2509, February 1999.

[RFC2509] EnganとM.とCasnerとS.とC.ボルマン、「pppの上のIPヘッダー圧縮」、RFC2509、1999年2月。

Svanbro                      Informational                      [Page 9]

RFC 3409         Lower Layer Guidelines for Robust HC      December 2002

Svanbroの情報[9ページ]のRFC3409は2002年12月に強健なHCのための層のガイドラインを下ろします。

   [RFC3095]   Borman, 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.

[RFC3095] ボーマンと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月。

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

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

7.  Author's Address

7. 作者のアドレス

   Krister Svanbro
   Box 920
   Ericsson AB
   SE-971 28 Lulea, Sweden

Krister Svanbro箱920のエリクソンAB SE-971 28ルーレオ(スウェーデン)

   Phone: +46 920 20 20 77
   Fax:   +46 920 20 20 99
   EMail: krister.svanbro@ericsson.com

以下に電話をしてください。 +46 920 20 20 77、Fax: +46 920 20 20 99はメールされます: krister.svanbro@ericsson.com

Svanbro                      Informational                     [Page 10]

RFC 3409         Lower Layer Guidelines for Robust HC      December 2002

Svanbroの情報[10ページ]のRFC3409は2002年12月に強健なHCのための層のガイドラインを下ろします。

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機能のための基金は現在、インターネット協会によって提供されます。

Svanbro                      Informational                     [Page 11]

Svanbro情報です。[11ページ]

一覧

 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 

スポンサーリンク

<演算子 小さい

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

上に戻る