Network Working Group H. Hannu
Request for Comments: 3322 Ericsson
Category: Informational January 2003
Signaling Compression (SigComp) Requirements & Assumptions
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 (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
The purpose of this document is to outline requirements and motivations for the development of a scheme for compression and decompression of messages from signaling protocols. In wireless environments and especially in cellular systems, e.g., GSM (Global System for Mobile communications) and UMTS (Universal Mobile Telecommunications System), there is a need to maximize the transport efficiency for data over the radio interface. With the introduction of SIP/SDP (Session Initiation Protocol/Session Description Protocol) to cellular devices, compression of the signaling messages should be considered in order to improve both service availability and quality, mainly by reducing the user idle time, e.g., at call setup.
このドキュメントの目的は、シグナリングプロトコルからのメッセージの圧縮と解凍のためのスキームの開発のための要件や動機を概説することです。無線環境では、特にセルラーシステム、例えば、GSM（移動通信用グローバルシステム）およびUMTS（ユニバーサル・モバイル・テレコミュニケーション・システム）において、無線インタフェースを介してデータの輸送効率を最大化する必要があります。携帯デバイスへのSIP / SDP（セッション開始プロトコル/セッション記述プロトコル）の導入により、シグナリングメッセージの圧縮は呼び出しで、主に例えば、ユーザーのアイドル時間を減らすことによって、サービスの可用性と品質の両方を改善するために考慮されるべきですセットアップ。
Table of Contents
目次
1. Introduction....................................................2
1.1. Protocol Characteristics......................................2
1.2. Cellular System Radio Characteristics.........................3
2. Motivation for Signaling Reduction..............................4
2.1. Estimation of Call Setup Delay Using SIP/SDP..................4
3. Alternatives for Signaling Reduction............................6
4. Assumptions.....................................................7
5. Requirements....................................................8
5.1. General Requirements..........................................8
5.2. Performance Requirements......................................9
6. Security Considerations.........................................11
7. IANA Considerations.............................................11
8. References......................................................11
9. Author's Address................................................12
10. Full Copyright Statement.......................................13
In wireless environments, and especially in cellular systems, such as GSM/GPRS, there is a need to maximize the transport efficiency of data over the radio interface. The radio spectrum is rather expensive and must be carefully used. Therefore, the cellular systems must support a sufficient number of users to make them economically feasible. Thus, there is a limitation in the per user bandwidth.
無線環境では、特にこのようなGSM / GPRSなどのセルラーシステムにおいて、無線インタフェースを介してデータの転送効率を最大にする必要があります。無線スペクトルは、かなり高価であり、慎重に使用する必要があります。したがって、セルラ・システムは、彼らが経済的に実現可能にするために、ユーザーの十分な数をサポートしている必要があります。このように、ユーザごとの帯域幅には限界があります。
Compressing the headers of the network and transport protocols used for carrying user data is one way to make more efficient use of the scarce radio resources [ROHC]. However, compression of the messages from signaling protocols, such as SIP/SDP, should also be considered to increase the radio resource usage even further. Compression will also improve the service quality by reducing the user idle time at e.g., call setup. When IP is used end-to-end, new applications, such as streaming, will be brought to tiny end-hosts, such as cellular devices. This will introduce additional traffic in cellular systems. Compression of signaling messages, such as RTSP [RTSP], should also be considered to improve both the service availability and quality.
ユーザデータを搬送するために使用されるネットワーク及びトランスポートプロトコルのヘッダを圧縮すると、希少な無線リソース[ROHC]をより効率的に利用する1つの方法です。しかしながら、そのようなSIP / SDPなどのシグナリングプロトコルからのメッセージの圧縮は、またさらに、無線リソース使用量を増加させるために考慮されるべきです。圧縮はまた、例えば、呼セットアップ時にユーザーのアイドル時間を減らすことによって、サービス品質を向上します。 IPは、エンドツーエンドを使用する場合は、そのようなストリーミングなどの新しいアプリケーションは、このような携帯機器などの小型のエンドホストにもたらされるだろう。これは、セルラーシステムに追加のトラフィックを紹介します。そのようなRTSP [RTSP]としてシグナリングメッセージの圧縮は、また、サービスの可用性と品質の両方を改善するために考慮されるべきです。
New services with their corresponding signaling protocols make it reasonable to consider a scheme that is generic. The scheme should be generic in the meaning that the scheme can efficiently be applied to arbitrary protocols with certain characteristics, such as the ASCII based protocols SIP and RTSP.
それらに対応するシグナリングプロトコルを使用して新しいサービスは、それが合理的で汎用的なスキームを検討することにします。スキームはスキームは効率よくASCIIベースのプロトコルSIPおよびRTSPのような特定の特性を有する任意のプロトコルに適用することができるという意味で汎用的であるべきです。
The following application signaling protocols are examples of protocols that are expected to be commonly used in the future. Some of their characteristics are described below.
プロトコルシグナリング次のアプリケーションは、一般的に、将来的に使用することが期待されているプロトコルの例です。その特性のいくつかを以下に記載されています。
The Session Initiation Protocol [SIP] is an application layer protocol for establishing, modifying and terminating multimedia sessions or calls. These sessions include Internet multimedia conferences, Internet telephony and similar applications. SIP can be used over either TCP [TCP] or UDP [UDP]. SIP is a text based protocol, using ISO 10646 in UTF-8 encoding.
セッション開始プロトコル[SIP]は、確立し、修正し、マルチメディアセッションまたは通話を終了するためのアプリケーション層プロトコルです。これらのセッションは、インターネットマルチメディア会議、インターネット電話と同様のアプリケーションが含まれます。 SIPは、TCP [TCP]またはUDP [UDP]のいずれかを介して使用することができます。 SIPは、UTF-8エンコーディングにISO 10646を用いて、テキストベースのプロトコルです。
The Session Description Protocol [SDP] is used to advertise multimedia conferences and communicate conference addresses and conference tool specific information. It is also used for general real-time multimedia session description purposes. SDP is carried in the message body of SIP and RTSP messages. SDP is text based using the ISO 10646 character set in UTF-8 encoding.
セッション記述プロトコルは、[SDP]マルチメディア会議をアドバタイズし、会議アドレスと会議ツール固有の情報を通信するために使用されます。また、一般的なリアルタイムのマルチメディアセッション記述の目的のために使用されます。 SDPは、SIPおよびRTSPメッセージのメッセージ本体で搬送されます。 SDPは、UTF-8エンコーディングにISO 10646文字セットを使用してベースのテキストです。
The Real Time Streaming Protocol [RTSP] is an application level protocol for controlling the delivery of data with real-time properties, such as audio and video. RTSP may use UDP or TCP (or other) as a transport protocol. RTSP is text based using the ISO 10646 character set in UTF-8 encoding.
リアルタイムストリーミングプロトコル[RTSP]は、オーディオやビデオなどのリアルタイム特性を有するデータの配信を制御するためのアプリケーションレベルのプロトコルです。 RTSPは、トランスポートプロトコルとしてUDPまたはTCP（または他の）を使用することができます。 RTSPは、UTF-8エンコーディングにISO 10646文字セットを使用してベースのテキストです。
The above protocols have many similarities. These similarities will have implications on solutions to the problems they create in conjunction with e.g., cellular radio access. The similarities include:
上記のプロトコルは、多くの類似点を持っています。これらの類似性は、彼らは、例えば、セルラ無線アクセスと併せて作成する問題の解決策の意味合いを持つことになります。類似点は次のとおりです。
- Requests and reply characteristics. When a sender sends a request, it stays idle until it has received a response. Hence, it typically takes a number of round trip times to conclude e.g., a SIP session.
- 要求と応答特性。送信者が要求を送信すると、応答を受信するまで、それがアイドル状態のままです。したがって、それは、典型的には、例えば、SIPセッションを終了するために往復回数をとります。
- They are ASCII based.
- 彼らは、ASCIIベースです。
- They are generous in size in order to provide the necessary information to the session participants.
- 彼らは、セッション参加者に必要な情報を提供するために、サイズに寛大です。
- SIP and RTSP share many common header field names, methods and status codes. The traffic patterns are also similar. The signaling is carried out primarily under the set up phase. For SIP, this means that the majority of the signaling is carried out to set up a phone call or multimedia session. For RTSP, the majority of the signaling is done before the transmission of application data.
- SIPおよびRTSPは多くの共通ヘッダフィールド名、メソッドおよびステータスコードを共有します。トラフィックパターンにも似ています。シグナリングは、主にセットアップ相の下で行われます。 SIPの場合、これは、シグナリングの大部分は、電話またはマルチメディアセッションを設定するために行われることを意味しています。 RTSPため、シグナリングの大部分は、アプリケーションデータの送信前に行われます。
Partly to enable high utilization of cellular systems, and partly due to the unreliable nature of the radio media, cellular links have characteristics that differ somewhat from a typical fixed link, e.g., copper or fiber. The most important characteristics are the lossy behavior of cellular links and the large round trip times.
一部のセルラーシステムの高い利用を可能にするために、無線媒体の信頼できない性質に部分的に起因する、セルラリンクは、一般的な固定されたリンク、例えば、銅またはファイバから幾分異なる特性を有します。最も重要な特徴は、携帯リンクや大型往復時間の非可逆動作です。
The quality in a radio system typically changes from one radio frame to another due to fading in the radio channel. Due to the nature of the radio media and interference from other radio users, the average bit error rate (BER) can be 10e-3 with a variation roughly between 10e-2 to 10e-4. To be able to use the radio media with its error characteristics, methods such as forward error correction (FEC) and interleaving are used. If these methods were not used, the BER of a cellular radio channel would be around 10 %. Thus, radio links are, by nature, error prone. The final packet loss rate may be further reduced by applying low level retransmissions (ARQ) over the radio channel; however, this trades decreased packet loss rate for a larger delay. By applying methods to decrease BER, the system delay is increased. In some cellular systems, the algorithmic channel round trip delay is in the order of 80 ms. Other sources of delays are DSP-processing, node-internal delay and transmission. A general value for the RTT is difficult to state, but it might be as high as 200 ms.
無線システム内の品質は、典型的に起因し、無線チャネルにおけるフェージングに別の無線フレームから変化します。他の無線ユーザーからの無線媒体および干渉の性質のために、平均ビット誤り率（BER）は10E-4とほぼ10E-2との間の変化で10E-3であることができます。その誤差特性と無線メディアを使用できるようにするために、前方誤り訂正（FEC）及びインターリービングなどの方法が用いられています。これらの方法を使用しなかった場合、セルラ無線チャネルのBERは約10％であろう。このように、無線リンクは、自然、エラーが発生しやすいことで、あります。最終的なパケット損失率は、さらに、無線チャネルを介してローレベルの再送信（ARQ）を適用することによって減少させることができます。しかし、この取引は、より大きな遅延のためのパケット損失率を減少させました。 BERを減少させる方法を適用することによって、システムの遅延が増大します。いくつかのセルラシステムでは、アルゴリズムチャネルラウンドトリップ遅延は、80ミリ秒のオーダーです。遅延の他の供給源は、DSP処理、ノード内部遅延と伝送されています。 RTTのための一般的な値は、状態に困難であり、それは200ミリ秒と高いかもしれません。
For cellular systems it is of vital importance to have a sufficient number of users per cell; otherwise the system cost would prohibit deployment. It is crucial to use the existing bandwidth carefully; hence the average user bit rate is typically relatively low compared to the average user bit rate in wired line systems. This is especially important for mass market services like voice.
セルラーシステムでは、それは、セルあたりのユーザーの十分な数を持つことが極めて重要です。そうでない場合は、システムのコストは、展開を禁止します。慎重に、既存の帯域幅を使用することが重要です。したがって平均的なユーザ・ビット・レートは、有線システムにおける平均的なユーザ・ビット・レートに比べて典型的には比較的低いです。これは、音声のようなマスマーケットサービスのために特に重要です。
The need for solving the problems caused by the signaling protocol messages is exemplified in this chapter by looking at a typical SIP/SDP Call Setup sequence over a narrow band channel.
シグナリングプロトコルメッセージによる問題を解決するための必要性は、狭帯域チャネルを介して、典型的なSIP / SDPコール設定シーケンスを見ることで、この章に例示されています。
Figure 2.1 shows an example of SIP signaling between two termination points with a wireless link between, and the resulting delay under certain system assumptions.
図2.1との間の無線リンク、及び特定のシステムの仮定の下で得られた遅延を有する2つの終端点との間にSIPシグナリングの一例を示しています。
It should be noted that the used figures represent a very narrow band link. E.g., a WCDMA system can provide maximum bit rates up to 2 Mbits/s in ideal conditions, but that means one single user would consume all radio resources in the cell. For a mass market service such as voice, it is always crucial to reduce the bandwidth requirements for each user.
使用の数字は非常に狭い帯域のリンクを表すことに留意すべきです。例えば、WCDMAシステムでは、理想的な条件で2メガビット/秒までの最大ビットレートを提供することができ、それは、単一のユーザがセル内の全ての無線リソースを消費することを意味します。音声などのマスマーケットサービスの場合は、各ユーザーの帯域幅の要件を減らすために常に重要です。
Client Network-Proxy Size [bytes] Time [ms]
| |
|---------- INVITE --------->| 620 517+70=587
| |
|<-- 183 Session progress ---| 500 417+70=487
| |
|---------- PRACK ---------->| 250 208+70=278
| |
|<----- 200 OK (PRACK) ------| 300 250+70=320
: :
|<...... RSVP and SM .......>|
: :
|---------- COMET ---------->| 620 517+70=587
| |
|<----- 200 OK (COMET) ------| 450
| | +
|<------ 180 Ringing --------| 230 567+70=637
| |
|---------- PRACK ---------->| 250 208+70=278
| |
|<----- 200 OK (PRACK) ------| 300
| | +
|<--------- 200 OK ----------| 450 625+70=695
| |
|----------- ACK ----------->| 230 192+70=262
Figure 2.1. SIP signaling delays assuming a link speed of 9600 bits/sec and a RTT of 140 ms.
図2.1。 9600ビット/秒と140ミリ秒のRTTのリンク速度を仮定してSIPシグナリング遅延。
The one way delay is calculated according to the following equation:
片道遅延は、以下の式に従って計算されます。
OneWayDelay = MessageSize[bits]/LinkSpeed[bits/sec] + RTT[sec]/2 (eq. 1)
OneWayDelay = MESSAGESIZE [ビット] / LinkSpeed [ビット/秒] + RTT [秒] / 2（式1）
The following values have been used:
以下の値が使用されています：
RTT/2: 70 ms LinkSpeed 9.6 kbps
RTT / 2：70ミリ秒9.6 kbpsのをLinkSpeed
The delay formula is based on an approximation of a WCDMA radio access method for speech services. The approximation is rather crude. For instance, delays caused by possible retransmissions due to errors are ignored. Further, these calculations also assume that there is only one cellular link in the path and take delays in an eventual intermediate IP-network into account. Even if this approximation is crude, it is still sufficient to provide representative numbers and enable comparisons. The message size given in Figure 2.1, is typical for a SIP/SDP call setup sequence.
遅延式は、音声サービスのためのWCDMA無線アクセス方式の近似に基づいています。近似はかなり粗あります。たとえば、エラーによる可能性の再送による遅延は無視されます。さらに、これらの計算もパスで唯一つの細胞のリンクがあることを前提として考慮に最終的な中間IPネットワークの遅延を取ります。この近似が粗であっても、まだ代表番号を提供し、比較を可能にするのに十分です。図2.1で与えられたメッセージサイズは、SIP / SDP呼設定シーケンスのために典型的です。
Applying equation 1 to each SIP/SDP message shown in the example of Figure 2.1 gives a total delay of 4131 ms from the first SIP/SDP message to the last. The RSVP and Session Management (Radio Bearer setup), displayed in Figure 2.1, will add approximately 1.5 seconds to the total delay, using equation 1. However, there will also be RSVP and SM signaling prior to the SIP INVITE message to establish the radio bearer, which would add approximately another 1.5 seconds.
図2.1の例に示した各SIP / SDPメッセージに式1を適用すると、最後に最初のSIP / SDPメッセージから4131ミリ秒の全遅延を与えます。図2.1に表示されたRSVPおよびセッション管理（無線ベアラセットアップ）は、また、RSVPとSMは、無線を確立するためにINVITEメッセージをSIP前シグナリングが存在するであろう、しかし、式1を用いて、全遅延に約1.5秒を追加しますさらに約1.5秒を追加するベアラ、。
In [TSG] there is a comparison between GERAN call setup using SIP and ordinary GSM call setup. For a typical GSM call setup, the time is about 3.6 seconds, and for the case when using SIP, the call setup is approximately 7.9 seconds.
【TSG]にSIP及び通常のGSMコールセットアップを使用して、GERAN呼設定の間の比較があります。典型的なGSM呼設定のために、時間は約3.6秒で、SIPを使用する場合場合の、コールセットアップは、約7.9秒です。
Another situation that would benefit from reduced signaling is carrying signaling messages over narrow bandwidth links in mid-call. For GERAN, this will result in frame stealing with degraded speech quality as a result.
減少したシグナリングの恩恵を受ける別の状況は、通話中の狭い帯域幅リンク上でシグナリングメッセージを運んでいます。 GERANの場合、これは結果として劣化した音声品質と盗みフレームをもたらすであろう。
Thus, solutions are needed to reduce the signaling delay and the required bandwidth when considering both system bandwidth requirements and service setup delays.
このように、解決策は、システム帯域幅の要件とサービスのセットアップの遅延の両方を考慮したときに、シグナリング遅延と必要な帯域幅を削減するために必要とされます。
More or less attractive solutions to the previously mentioned problems can be outlined:
前述の問題に多かれ少なかれ魅力的なソリューションを概説することができます。
- Increase the user bit rate
- ユーザーのビットレートを増やします
An increase of the bit rate per user will decrease the number of users per cell. There exist systems (for example WCDMA) which can provide high bit rates and even variable rates, e.g., at the setup of new sessions. However, there are also systems, e.g., GSM/EDGE, where it is not possible to reach these high bit rates in all situations. At the cell borders, for example, the signal strength to noise ratio will be lower and result in a lower bit rate. In general, an unnecessary increase of the bit rate should be avoided due to the higher system cost introduced and the possibility of denial of service. The latter could, for example, be caused by lack of enough bandwidth to support the sending of the large setup message within a required time period, which is set for QoS reasons.
ユーザーあたりのビットレートの上昇は、細胞あたりのユーザー数が減少します。新規セッションのセットアップ時に、例えば、高ビットレートも変動金利を提供することができます（たとえば、WCDMA用）のシステムが存在します。しかし、システムは、すべての状況で、これらの高いビットレートに到達することは不可能である例えば、GSM / EDGE、もあります。セル境界で、例えば、信号対雑音比強度が低くなり、より低いビットレートをもたらします。一般的に、ビットレートの不要な増加は、導入されたより高いシステム・コスト及びサービス拒否の可能性を避けるべきです。後者は、例えば、QoSの上の理由から設定された所要時間内に大セットアップ・メッセージの送信をサポートするのに十分な帯域幅の不足によって引き起こされることができます。
- Decrease the RTT of the cellular link
- セルラーリンクのRTTを下げます
Decreasing the RTT would require substantial system changes and is thus not feasible in the short term. Further, the RTT-delay caused by interleaving and FEC will always have to be present regardless of which system is used. Otherwise the BER will be too high for the received data to be useful, or alternatively trigger retransmissions giving an average total delay of the same or higher magnitude.
RTTを小さくすると、大幅なシステム変更を必要とし、短期的にはこれは実現可能ではないでしょう。さらに、インタリーブ及びFECによって引き起こさRTT遅延は関係なく、常に使用されるシステムの存在する必要があります。受信したデータが有用であるか、あるいは同等以上の大きさの平均総遅延を与える再送をトリガするためにそうでなければBERが高すぎるであろう。
- Optimize message sequence for the protocols
- プロトコルのための最適化のメッセージシーケンス
If the request/response pattern could be eased up, then "keeping the pipe full" could be a way forward. Thus, instead of following the message sequence described in Figure 4.2, more than one message would be sent in a row, even though no response has been received. However, this would entail protocol changes and may be difficult at the current date.
要求/応答パターンがアップ緩和することができれば、その後、「完全なパイプを維持することは、」進むべき道である可能性があります。したがって、代わりに、図4.2に記載のメッセージシーケンスを、以下の、複数のメッセージは、応答が受信されていないにも関わらず、行に送信されます。しかし、これは、プロトコルの変更を伴うだろうし、現在の日付で難しいかもしれません。
- Protocol stripping
- プロトコルストリッピング
Removing fields from a message would decrease the size of the messages to some extent. However, this would cause the loss of transparency and thus violate the End-to-End principle and is thus not desirable.
メッセージからフィールドを削除すると、ある程度メッセージのサイズを減少させるであろう。しかし、これは、透明性の損失を引き起こすため、エンド・ツー・エンド原理に違反するため、望ましくありません。
- Compression
- 圧縮
By compressing messages, the impact of the mentioned problems could be decreased. Compared to the other possible solutions compression can be made, and must be, transparent to the end-user application. Thus, compression seems to be the most attractive way forward.
メッセージを圧縮することにより、前述の問題の影響を減少させることができました。他の可能な解決策の圧縮に比べ行うことができ、かつ、エンドユーザアプリケーションに対して透明でなければなりません。このように、圧縮は前方の最も魅力的な方法であると思われます。
- Negotiation
- 交渉
How the usage of compression is negotiated is out of the scope for this compression solution and must be handled by e.g., the protocol the messages of which are to be compressed.
どの圧縮の使用がネゴシエートされ、この圧縮ソリューションの範囲外であり、例えば、圧縮されるべきメッセージれたプロトコルによって処理されなければなりません。
- Reliable transport
- 信頼性の高い輸送
With reliable transport, it is assumed that a transport recovered from data that is damaged, lost, duplicated, or delivered out of order, e.g., [TCP].
信頼性の高い輸送と、トランスポートが破損しているデータから回復しているものとする、[TCP]、例えば、複製、失われた、または順不同配信。
- Unreliable transport
- 信頼性の低い輸送
With unreliable transport, it is assumed that a transport does not have the capabilities of a reliable transport, e.g., [UDP].
信頼性の低いトランスポートを使用すると、[UDP]、例えば、トランスポートは信頼性の高い輸送能力を持っていないことが想定されます。
This chapter states requirements for a signaling compression scheme to be developed in the IETF ROHC WG.
この章では、IETF ROHC WGで開発されるシグナリング圧縮方式の要件を述べています。
The requirements are divided into two parts. Section 5.1 sets general requirements concerning the Internet infrastructure, while Section 5.2 sets requirements on the scheme itself.
要件は、次の2つの部分に分かれています。 5.1節セットインターネットインフラに関する一般的な要件、しばらくスキーム自体のセクション5.2を設定要件。
1. Transparency: When a message is compressed and then decompressed, the result must be bitwise identical to the original message.
1.透明性：メッセージを圧縮し、その後解凍された場合、結果は、元のメッセージと同じビット単位されなければなりません。
Justification: This is to ensure that the compression scheme will
not cause problems for any current or future part of the Internet
infrastructure.
Note: See also requirement 9.
注：また、要件9を参照してください。
2. Header compression coexistence: The compression scheme must be able to coexist with header compression, especially the ROHC protocol.
2.ヘッダ圧縮共存：圧縮方式は、ヘッダ圧縮、特にROHCプロトコルと共存することができなければなりません。
Justification: Signaling compression is used because there is a
need to conserve bandwidth usage. In that case, header
compression will likely be needed too.
3a. Compatibility: The compression scheme must be constructed in such a way that it allows the above protocols' mechanisms to negotiate whether the compression scheme is to be applied or not.
図3（a）。互換性：圧縮方式は、圧縮方式が適用されるか否かを交渉するために、上記のプロトコールメカニズムを可能にするように構成されなければなりません。
Justification: Two entities must be able to communicate
regardless if the signaling compression scheme is implemented at
both entities or not.
3b. Ubiquity: Modifications to the protocols generating the messages that are to be compressed, must not be required for the compression scheme to work.
図3b。ユビキタス：圧縮方式が機能するために圧縮されるメッセージを生成するプロトコルへの変更は、必要とされてはなりません。
Justification: This will simplify deployment of the compression
scheme.
Note: This does not preclude making extensions, which are related to the signaling compression scheme, to existing protocols, as long as the extensions are backward compatible.
注意：これは、限りの拡張子は下位互換性があるとして、既存のプロトコルに、シグナリング圧縮方式に関連する拡張を作る排除するものではありません。
4. Generality: Compression of arbitrary message streams must be supported. The signaling compression scheme must not be limited to certain protocols, traffic patterns or sessions. It must not assume any message pattern to be able to perform compression.
4.一般性：任意のメッセージ・ストリームの圧縮はサポートされなければなりません。シグナリング圧縮方式は、特定のプロトコル、トラフィックパターンまたはセッションに限定されてはなりません。これは、圧縮を行うことができるように任意のメッセージパターンを想定してはいけません。
Justification: There might be a future need for compression of
different ASCII based signaling protocols. This requirement will
minimize future work.
Note: This does not preclude optimization for certain streams.
注意：これは、特定のストリームの最適化を妨げるものではありません。
5. Unidirectional routes: The compression scheme must be able to operate on unidirectional routes, i.e., without explicit feedback messages from the decompressor.
5.単方向経路：圧縮方式が減圧装置からの明示的なフィードバックメッセージなしで、すなわち、単方向経路上で動作することができなければなりません。
Note: Implementations on unidirectional routes might possibly
show a degraded performance compared to implementations on bi-
directional routes.
6. Transport: The solution must work for both unreliable and reliable underlying transport protocols, e.g., UDP and TCP.
6.交通：ソリューションは信頼できないと信頼性の基盤となるトランスポートプロトコル、例えば、UDPとTCPの両方のために働く必要があります。
Justification: The protocols, which generate the messages that
are to be compressed, may use either an unreliable or a reliable
underlying transport.
Note: This should not be taken to mean that the same set of solution mechanisms must be used over both unreliable and reliable transport.
注：これは解決メカニズムの同じセットが信頼できないと信頼性の両方のトランスポート上で使用されなければならないことを意味すると解釈すべきではありません。
The performance requirements in this section and the following subsections are valid for both unreliable and reliable underlying transport.
このセクションの性能要件と以下のサブセクションでは、両方の信頼性が低く、信頼性の根本的な輸送のために有効です。
7. Scalability: The scheme must be flexible to accommodate a range of compressors/decompressors with varying memory and processor capabilities.
7.スケーラビリティ：スキームは、様々なメモリおよびプロセッサ能力を有する圧縮/解凍の範囲に対応するために柔軟でなければなりません。
Justification: A primary target for the signaling compression
scheme is cellular systems, where the mobile terminals have
varying capabilities.
8. Delay: The signaling compression must not noticeably add to the delay experienced by the end user.
8.遅延：シグナリング圧縮が著しく、エンドユーザーが経験する遅延に追加してはいけません。
Justification: Reduction of the user experienced delay is the
main purpose of signaling compression.
Note: This requirement is intended to prevent schemes that achieve compression efficiency at the expense of delay, i.e., queuing of messages to improve the compression efficiency should be avoided.
注：この要件は避けるべきである圧縮効率を改善するためにメッセージをキューイング、すなわち遅延を犠牲にして圧縮効率を達成するスキームを防止することを意図しています。
The following requirements are grouped into two subsections, a robustness section and a compression efficiency section.
以下の要件は、2つのサブセクション、堅牢性セクション及び圧縮効率のセクションにグループ化されます。
The requirements in this section concern the issue of when compressed messages should be correctly decompressed. The transparency requirement (first requirement) covers the issue with faulty decompressed messages.
圧縮されたメッセージの問題を正しく解凍する必要があります。このセクションの懸念で要件。透明性の要件（最初の要件）が故障し、解凍メッセージの問題をカバーしています。
9. Residual errors: The compression scheme must be resilient against errors undetected by lower layers, i.e., the probability of incorrect decompression caused by such undetected errors must be low.
9.残留誤差：圧縮方式は、下位層で検出されないエラーに対する弾性でなければならない、すなわち、そのような検出されないエラーに起因する誤った減圧の確率が低くなければなりません。
Justification: A primary target for the signaling compression
scheme is cellular systems, where undetected errors might be
introduced on the cellular link.
10. Error propagation: Propagation of errors due to signaling compression should be kept at an absolute minimum. Loss or damage to a single or several messages, between compressor and decompressor should not prevent compression and decompression of later messages.
10.エラー伝播：圧縮シグナリングによるエラーの伝播が最小限に保たれるべきです。コンプレッサーと減圧器との間に単一または複数のメッセージの損失や損傷は、後でメッセージの圧縮と解凍を妨げるべきではありません。
Justification: Error propagation reduces resource utilization and
quality.
11. Delay: The compression scheme must be able to perform compression and decompression of messages under all expected delay conditions.
11.ディレイ：圧縮方式は、すべての期待遅延条件下でのメッセージの圧縮と解凍を行うことができなければなりません。
This section states requirements related to compression efficiency.
このセクションでは、圧縮効率に関連する要件を述べています。
12. Message loss: Loss or damage to a single or several messages, on the link between compressor and decompressor, should not prevent the usage of later messages in the compression and decompression process.
12.メッセージの損失：単一または複数のメッセージの損失または損傷は、コンプレッサとデコンプレッサとの間のリンク上で、圧縮および伸張プロセスの後のメッセージの使用を妨げるべきではありません。
13. Moderate message misordering: The scheme should allow for the correct decompression of messages, that have been moderately misordered (1-2 messages) between compressor and decompressor. The scheme should not prevent the usage of later messages in the compression and decompression process.
13.中程度メッセージ誤った順序：スキームがコンプレッサとデコンプレッサとの間の適度misorderedされたメッセージの正しい解凍、（1-2メッセージ）を可能にすべきです。スキームは、圧縮および伸張プロセスの後のメッセージの使用を妨げるべきではありません。
Justification: Misordering is frequent on the Internet, and this
kind of misordering is common.
A protocol specified to meet these requirements must be able to cope with packets that have undergone security measures, such as encryption, without adding any security risks. This document, by itself however, does not add any security risks.
これらの要件を満たすために指定されたプロトコルは、セキュリティ上のリスクを追加することなく、暗号化などのセキュリティ対策を、受けたパケットに対処できなければなりません。この文書では、しかし、それ自体で、任意のセキュリティリスクを追加しません。
A protocol which meets these requirements may require the IANA to assign various numbers. This document by itself however, does not require any IANA involvement.
これらの要件を満たしているプロトコルは、様々な数を割り当てるIANAを必要とするかもしれません。それ自体でこのドキュメントは、しかし、任意のIANAの関与を必要としません。
[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): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[ROHC]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.とH.鄭、「ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTP、UDP、ESP 「、および圧縮されていない、RFC 3095、2001年7月。
[RTSP] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RTSP] SchulzrinneとH.とラオとA.とR. Lanphier、 "リアルタイムストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[SDP] Handley, H. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[SDP]ハンドリー、H.およびV. Jacobson氏、 "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[SIP]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、2002年6月。
[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[UDP]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[TSG] Nortel Networks, "A Comparison Between GERAN Packet-Switched Call Setup Using SIP and GSM Circuit-Switched Call Setup Using RIL3-CC, RIL3-MM, RIL3-RR, and DTAP", 3GPP TSG GERAN #2, GP-000508, 6-10 November 2000.
【TSG]ノーテルネットワーク、3GPP TSG GERAN＃2、GP- "RIL3-CC、RIL3-MM、RIL3-RR、及びDTAPを使用してSIPを用いGERANパケット交換呼セットアップおよびGSM回線交換呼セットアップの比較" 000508、6-10 2000年11月。
Hans Hannu Box 920 Ericsson AB SE-971 28 Lulea, Sweden
彼のハンヌボックス920エリクソンAB、SE-971 28ルーレオ、スウェーデン
Phone: +46 920 20 21 84 EMail: hans.hannu@epl.ericsson.se
電話：+46 920 20 21 84 Eメール：hans.hannu@epl.ericsson.se
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。