[要約] 要約： RFC 3322は、SigComp（Signaling Compression）の要件と前提条件について説明しています。SigCompは、シグナリングメッセージの圧縮を可能にするプロトコルです。目的： RFC 3322の目的は、SigCompの要件と前提条件を明確にすることで、シグナリングメッセージの効率的な圧縮を実現するためのガイドラインを提供することです。
Network Working Group H. Hannu
Request for Comments: 3322 Ericsson
Category: Informational January 2003
Signaling Compression (SigComp) Requirements & Assumptions
シグナリング圧縮（SIGCOMP）要件と仮定
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.
Copyright（c）The Internet Society（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-3であり、約10E-2から10E-4の間の変動があります。エラー特性を備えたラジオメディアを使用できるようにするには、フォワードエラー補正（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 MBITS/sの最大ビットレートを提供できますが、それは1人のユーザーがセル内のすべての無線リソースを消費することを意味します。音声などの大規模な市場サービスの場合、各ユーザーの帯域幅要件を減らすことが常に重要です。
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 [bits]/linkspeed [bits/sec] rtt [sec]/2（eq。1）
The following values have been used:
次の値が使用されています。
RTT/2: 70 ms LinkSpeed 9.6 kbps
RTT/2：70 ms LinkSpeed 9.6 kbps
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無線アクセス方法の近似に基づいています。近似はかなり粗いです。たとえば、エラーによる再送信の可能性によって引き起こされる遅延は無視されます。さらに、これらの計算では、パスにセルラーリンクが1つしかないと想定しており、最終的な中間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 msの合計遅延が得られます。図2.1に表示されているRSVPおよびセッション管理（ラジオベアラーのセットアップ）は、式1を使用して、合計遅延に約1.5秒を追加します。ただし、SIP招待メッセージの前にRSVPとSMシグナルもラジオを確立する前に、RSVPとSMシグナルもあります。ベアラー。これは約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を使用したGERANコールセットアップと通常のGSMコールセットアップの比較があります。典型的な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-Delayは常に存在する必要があります。それ以外の場合、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.
3a。互換性：圧縮スキームは、上記のプロトコルのメカニズムが圧縮スキームを適用するかどうかを交渉できるように構築する必要があります。
Justification: Two entities must be able to communicate regardless if the signaling compression scheme is implemented at both entities or not.
正当化：2つのエンティティが両方のエンティティで実装されているかどうかにかかわらず、2つのエンティティが通信できる必要があります。
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.
正当化：さまざまなASCIIベースのシグナル伝達プロトコルの圧縮が将来的に必要である可能性があります。この要件は、将来の作業を最小限に抑えます。
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. 中程度のメッセージの誤用：スキームは、コンプレッサーと減圧装置の間で適度に誤用された（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] Bormann、C.、Burmeister、C.、Degermark、M.、Fukushima、H.、Hannu、H.、Jonsson、L-e。、Hakenberg、R.、Koren、T.、Le、K。、Liu、Liu、Z.、Martensson、A.、Miyazaki、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T。、およびH. Zheng、 "堅牢なヘッダー圧縮（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.、Rao、A。、およびR. Lanphier、「リアルタイムストリーミングプロトコル（RTSP）」、RFC 2326、1998年4月。
[SDP] Handley, H. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[SDP] Handley、H。and 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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、E。RFC 3261、2002年6月。
[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[UDP] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP] Postel、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] Nortel Networks、「RIL3-CC、RIL3-MM、RIL3-RR、およびDTAPを使用したSIPとGSM回路スイッチのコールセットアップを使用したGERANパケットスイッチのコールセットアップの比較 "、3GPP TSG GERAN＃2、GP-000508、2000年11月6〜10日。
Hans Hannu Box 920 Ericsson AB SE-971 28 Lulea, Sweden
Hans Hannu Box 920 Ericsson AB SE-971 28 Lulea、Sweden
Phone: +46 920 20 21 84
EMail: hans.hannu@epl.ericsson.se
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。