RFC3322 日本語訳

Network Working Group                                           H. Hannu
Request for Comments: 3322                                      Ericsson
Category: Informational                                     January 2003

コメントを求めるワーキンググループH.ハンヌの要求をネットワークでつないでください: 3322年のエリクソンカテゴリ: 情報の2003年1月

       Signaling Compression (SigComp) Requirements & Assumptions

シグナリング圧縮要件と仮定(SigComp)

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

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

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(モバイルコミュニケーションのためのグローバルなSystem)、およびUMTS(普遍的なモバイルTelecommunications System)に、ラジオインタフェースの上にデータのために輸送効率を最大にする必要があります。 セル装置へのSIP/SDP(セッションInitiationプロトコル/セッション記述プロトコル)の導入で、シグナリングメッセージの要約はサービスの有用性と品質の両方を改良するために考えられるべきです、主にユーザ遊休時間を短縮することによって、例えば、呼び出しセットアップで。

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

1. 序論…2 1.1. 特性について議定書の中で述べてください…2 1.2. セルラ方式ラジオの特性…3 2. シグナリング減少に関する動機…4 2.1. 一口/SDPを使用する呼び出しセットアップ遅れに関する見積り…4 3. シグナリング減少のための代替手段…6 4. 仮定…7 5. 要件…8 5.1. 一般要件…8 5.2. パフォーマンス要件…9 6. セキュリティ問題…11 7. IANA問題…11 8. 参照…11 9. 作者のアドレス…12 10. 完全な著作権宣言文…13

Hannu                        Informational                      [Page 1]

RFC 3322           SigComp Requirements & Assumptions       January 2003

ハンヌ情報[1ページ]のRFC3322SigComp Requirementsと仮定2003年1月

1. Introduction

1. 序論

   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]にすることにおいて一方通行です。 しかしながら、また、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のように。

1.1. Protocol Characteristics

1.1. プロトコルの特性

   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.

以下のアプリケーションシグナリングプロトコルは将来一般的に使用されると予想されるプロトコルに関する例です。 それらの特性のいくつかが以下で説明されます。

1.1.1 SIP

1.1.1 一口

   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.

Session Initiationプロトコル[SIP]は、マルチメディアセッションを確立して、変更して、終えるための応用層プロトコルであるか呼びます。 これらのセッションはインターネットマルチメディア会議、インターネット電話、および同様のアプリケーションを含んでいます。 TCP[TCP]かUDP[UDP]のどちらかの上でSIPを使用できます。 UTF-8コード化にISO10646を使用して、SIPはテキストに基づいているプロトコルです。

Hannu                        Informational                      [Page 2]

RFC 3322           SigComp Requirements & Assumptions       January 2003

ハンヌ情報[2ページ]のRFC3322SigComp Requirementsと仮定2003年1月

1.1.2 SDP

1.1.2 SDP

   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.

Session記述プロトコル[SDP]は、マルチメディア会議の広告を出して、会議アドレスと会議ツール特殊情報を伝えるのに使用されます。 また、それは一般的なリアルタイムのマルチメディアセッション記述目的に使用されます。 SDPはSIPとRTSPメッセージのメッセージ本体で運ばれます。 SDPはUTF-8コード化にISO10646文字の組を使用することで基づくテキストです。

1.1.3 RTSP

1.1.3 RTSP

   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.

レアルTime Streamingプロトコル[RTSP]はリアルタイムの特性でデータの配送を制御するためのアプリケーションレベルプロトコルです、オーディオやビデオのように。 RTSPはトランスポート・プロトコルとしてUDPかTCP(何らかの)を使用するかもしれません。 RTSPはUTF-8コード化にISO10646文字の組を使用することで基づくテキストです。

1.1.4 Protocol Similarities

1.1.4 プロトコルの類似性

   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に関しては、アプリケーションデータの伝達の前にシグナリングの大部分をします。

1.2. Cellular System Radio Characteristics

1.2. セルラ方式ラジオの特性

   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.,

一部セルラ方式、および一部支払われるべきものの高使用率をラジオメディアの頼り無い本質に可能にするために、セルリンクには、例えば典型的な固定連結路といくらか異なっている特性があります。

Hannu                        Informational                      [Page 3]

RFC 3322           SigComp Requirements & Assumptions       January 2003

ハンヌ情報[3ページ]のRFC3322SigComp Requirementsと仮定2003年1月

   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.

ラジオチャンネルを次第にはっきりするためラジオシステムの品質は1個のラジオフレームから別のものに通常変化します。 他のラジオユーザからのラジオメディアと干渉の本質のために、平均したビット誤り率(BER)はおよそ10e-4への10e-2の間の変化を伴う10e-3であるかもしれません。 誤りの特性があるラジオメディアを使用できるように、前進型誤信号訂正などの方法(FEC)とインターリービングは使用されています。 これらの方法が使用されないなら、セルラジオチャンネルのBERはおよそ10%でしょうに。 したがって、生来、ラジオリンクは誤り傾向があります。 最終的なパケット損失率は低レベル「再-トランスミッション」(ARQ)をラジオチャンネルの上に適用することによって、さらに低下するかもしれません。 しかしながら、これは、より大きい遅れの減少しているパケット損失率を取り引きします。 BERを減少させる方法を適用することによって、システム遅れは増加されています。 いくつかのセルラ方式、アルゴリズムのチャンネル周遊旅行遅れには、原稿が80の注文にあります。遅れのOther源は、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.

セルラ方式に関しては、それは十分な数の1セルあたりのユーザがいるためには不可欠な重要性のものです。 さもなければ、システム費用は展開を禁止するでしょう。 慎重に既存の帯域幅を使用するのは重要です。 したがって、ワイヤードな回線システムの一般ユーザービット伝送速度と比べて、通常、一般ユーザービット伝送速度は比較的低いです。声のような大衆市場サービスに、これは特に重要です。

2. Motivation for Signaling Reduction

2. シグナリング減少に関する動機

   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 Call Setup系列を見ることによって、例示されます。

2.1 Estimation of Call Setup Delay Using SIP/SDP

2.1 一口/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メガビット/sを最大のビット伝送速度に理想的な状態で提供できますが、それは、1人のシングルユーザーがセルの中のすべてのラジオリソースを消費することを意味します。 声などの大衆市場サービスに、各ユーザのための帯域幅要件を減らすのはいつも重要です。

Hannu                        Informational                      [Page 4]

RFC 3322           SigComp Requirements & Assumptions       January 2003

ハンヌ情報[4ページ]のRFC3322SigComp Requirementsと仮定2003年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

クライアントネットワークプロキシサイズ[バイト]時間[ms]| | |---------- 招待--------->| 620 517+70=587 | | | <-- 183 セッション進歩---| 500 417+70=487 | | |---------- PRACK---------->| 250 208+70=278 | | | <、-、-、-、-- 200OK(PRACK)------| 300 250+70=320 : : |<… RSVPとSm…>| : : |---------- 彗星---------->| 620 517+70=587 | | | <、-、-、-、-- 200 OK(彗星)------| 450 | | + | <、-、-、-、-、-- 180 鳴ること--------| 230 567+70=637 | | |---------- PRACK---------->| 250 208+70=278 | | | <、-、-、-、-- 200OK(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。 SIPシグナリングは、原稿であると9600ビット/秒と140のRTTのリンク速度に仮定するのを遅らせます。

   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と等しいです。(eq。 1)

   The following values have been used:

以下の値は使用されました:

   RTT/2:                     70 ms
   LinkSpeed                  9.6 kbps

RTT/2: 70 ms LinkSpeed9.6キロビット毎秒

   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ネットワークでつなぐ経路と撮影には1個のセルリンクしかないと仮定します。 この近似が粗雑であっても、代表している数を提供して、比較を可能にするのはまだ十分です。 SIP/SDP呼び出しセットアップ系列に、図2.1で与えられたメッセージサイズは典型的です。

Hannu                        Informational                      [Page 5]

RFC 3322           SigComp Requirements & Assumptions       January 2003

ハンヌ情報[5ページ]のRFC3322SigComp Requirementsと仮定2003年1月

2.1.1 Delay Results

2.1.1 遅れ結果

   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を適用すると、4131msの総遅れは最初のSIP/SDPメッセージから最終になりまで与えられます。 図2.1に表示されたRSVPとSession Management(ラジオBearerセットアップ)は、およそ1.5秒が合計に延着すると言い足すでしょう、方程式1を使用して。 しかしながら、また、加えるだろうラジオ運搬人を確立するSIP INVITEメッセージの前に合図する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.

したがって、解決策が、システム帯域幅要件とサービスセットアップ遅れの両方を考えるとき、シグナリング遅れと必要な帯域幅を減少させるのに必要です。

3. Alternatives for Signaling Reduction

3. シグナリング減少のための代替手段

   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.

1ユーザあたりのビット伝送速度の増加は1セルあたりのユーザの数を減少させるでしょう。 高いビット伝送速度と変動金利さえ提供できるシステム(例えば、WCDMA)が存在しています、例えば、新しいセッションのセットアップのときに。 しかしながら、システムも、例えばGSM/EDGEがあります。そこでは、すべての状況におけるこれらの高いビット伝送速度に達するのが可能ではありません。 セル境界では、例えば、雑音比への信号強度は、低く、下側のビット伝送速度をもたらすでしょう。 一般に、ビット伝送速度の不要な増加は費用が紹介したより高いシステムとサービスの否定の可能性のため避けられるべきです。 例えば、後者はQoS理由に決められる必要な期間以内に大きいセットアップメッセージの発信を支持できるくらいの帯域幅の不足によって引き起こされる場合がありました。

Hannu                        Informational                      [Page 6]

RFC 3322           SigComp Requirements & Assumptions       January 2003

ハンヌ情報[6ページ]のRFC3322SigComp Requirementsと仮定2003年1月

   -  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で説明されたメッセージ順序に従うことの代わりに1つ以上のメッセージを並んで送るでしょう、応答を全く受けていませんが。 しかしながら、これは、プロトコル変化を伴って、現在の期日に難しいかもしれません。

   -  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.

メッセージから野原を取り除くと、メッセージのサイズはある程度減少するでしょう。 しかしながら、これは、透明の損失を引き起こして、その結果、Endから終わりへの原則に違反して、その結果、望ましくはありません。

   -  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.

メッセージを圧縮することによって、言及された問題の影響は減少できるでしょう。 比べて、もう片方の可能な解決策圧縮は、作ることができて、あるに違いありません。エンドユーザアプリケーションに、透明です。 したがって、圧縮は前方に最も魅力的な道であるように思えます。

4. Assumptions

4. 仮定

   -  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。]

Hannu                        Informational                      [Page 7]

RFC 3322           SigComp Requirements & Assumptions       January 2003

ハンヌ情報[7ページ]のRFC3322SigComp Requirementsと仮定2003年1月

   -  Unreliable transport

- 頼り無い輸送

      With unreliable transport, it is assumed that a transport does not
      have the capabilities of a reliable transport, e.g., [UDP].

頼り無い輸送で、輸送には信頼できる輸送、例えば、[UDP]の能力がないと思われます。

5. Requirements

5. 要件

   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は計画自体に必要条件を定めます。

5.1. General Requirements

5.1. 一般要件

   1.  Transparency: When a message is compressed and then decompressed,
       the result must be bitwise identical to the original message.

1. 透明: メッセージが圧縮されて、次に、減圧されるとき、結果はオリジナルのメッセージと同じ状態でbitwiseすることであるに違いありません。

       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つの実体が、シグナリング圧縮技術が両方の実体で実行されるかどうか不注意に伝えることができなければなりません。

   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.

正当化: これは圧縮技術の展開を簡素化するでしょう。

Hannu                        Informational                      [Page 8]

RFC 3322           SigComp Requirements & Assumptions       January 2003

ハンヌ情報[8ページ]のRFC3322SigComp Requirementsと仮定2003年1月

       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.

以下に注意してください。 頼り無いものと同様に信頼できる輸送の上で同じセットの解決策メカニズムを使用しなければならないことを意味するためにこれを取るべきではありません。

5.2. Performance Requirements

5.2. パフォーマンス要件

   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.

正当化: シグナリング圧縮技術のための第一の目標は移動体端末には異なった能力があるところのセルラ方式です。

Hannu                        Informational                      [Page 9]

RFC 3322           SigComp Requirements & Assumptions       January 2003

ハンヌ情報[9ページ]のRFC3322SigComp Requirementsと仮定2003年1月

   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つの小区分、丈夫さ部、および圧縮効率部に分類されます。

5.2.1. Robustness

5.2.1. 丈夫さ

   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. 遅れ: 圧縮技術はすべての予想どおりの遅延条件のもとでメッセージの圧縮と減圧を実行できなければなりません。

Hannu                        Informational                     [Page 10]

RFC 3322           SigComp Requirements & Assumptions       January 2003

ハンヌ情報[10ページ]のRFC3322SigComp Requirementsと仮定2003年1月

5.2.2. Compression Efficiency

5.2.2. 圧縮効率

   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. メッセージmisorderingを加減してください: 計画はメッセージの正しい減圧を考慮するべきであり、それはコンプレッサーと減圧装置の間で適度にmisorderedされました(1-2 メッセージ)。 計画は圧縮と減圧の過程による後のメッセージの用法を防ぐべきではありません。

       Justification: Misordering is frequent on the Internet, and this
       kind of misordering is common.

正当化: Misorderingはインターネットで頻繁です、そして、この種類のmisorderingは一般的です。

6. Security Considerations

6. セキュリティ問題

   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.

これらの必要条件を満たすために指定されたプロトコルは安全策を受けたパケットに対処できなければなりません、暗号化などのように、どんなセキュリティ危険も加えないで。 しかしながら、これ自体が記録する、少しのセキュリティ危険も加えません。

7. IANA Considerations

7. IANA問題

   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かかわり合いも必要としません。

8. References

8. 参照

   [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.、バーマイスター、C.、デーゲルマルク、M.、福島、H.、ハンヌ、H.、イェンソン、L-E.、Hakenberg、R.、コーレン、T.、Le、K.、リュウ、Z.、Martensson、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH.ツェン、「体力を要しているヘッダー圧縮(ROHC):」 枠組みと4個のプロフィール: 「RTP、超能力であって、解凍されたUDP」、RFC3095、7月2001日

   [RTSP] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
          Protocol (RTSP)", RFC 2326, April 1998.

[RTSP] SchulzrinneとH.とラオとA.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」、RFC2326 1998年4月。

   [SDP]  Handley, H. and V. Jacobson, "SDP: Session Description
          Protocol", RFC 2327, April 1998.

[SDP] ハンドレー、H.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。

Hannu                        Informational                     [Page 11]

RFC 3322           SigComp Requirements & Assumptions       January 2003

ハンヌ情報[11ページ]のRFC3322SigComp Requirementsと仮定2003年1月

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

[一口] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。

   [UDP]  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
          1980.

[UDP] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。

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

[TCP] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、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]ノーテルネットワーク、「パケットで切り換えられた呼び出しセットアップ使用がちびちび飲むGERANとGSMでの比較はRIL3-cc、RIL3-mm、RIL3-RR、およびDTAPを使用することで呼び出しセットアップをサーキットで切り換えました」、3GPP TSG GERAN#2、GP000508、2000年11月6-10日。

9. Author's Address

9. 作者のアドレス

   Hans Hannu
   Box 920
   Ericsson AB
   SE-971 28 Lulea, Sweden

ハンスハンヌBox920エリクソンAB SE-971 28ルーレオ(スウェーデン)

   Phone:  +46 920 20 21 84
   EMail: hans.hannu@epl.ericsson.se

以下に電話をしてください。 +46 920 20 21 84はメールされます: hans.hannu@epl.ericsson.se

Hannu                        Informational                     [Page 12]

RFC 3322           SigComp Requirements & Assumptions       January 2003

ハンヌ情報[12ページ]のRFC3322SigComp Requirementsと仮定2003年1月

10.  Full Copyright Statement

10. 完全な著作権宣言文

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

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

Hannu                        Informational                     [Page 13]

ハンヌInformationalです。[13ページ]