RFC3242 日本語訳
3242 RObust Header Compression (ROHC): A Link-Layer Assisted Profilefor IP/UDP/RTP. L-E. Jonsson, G. Pelletier. April 2002. (Format: TXT=49007 bytes) (Obsoleted by RFC4362) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group L-E. Jonsson
Request for Comments: 3242 G. Pelletier
Category: Standards Track Ericsson
April 2002
ワーキンググループL-Eをネットワークでつないでください。 コメントを求めるイェンソンRequest: 3242年のG.ペレティアカテゴリ: 標準化過程エリクソン2002年4月
RObust Header Compression (ROHC):
A Link-Layer Assisted Profile for IP/UDP/RTP
体力を要しているヘッダー圧縮(ROHC): リンクレイヤはIP/UDP/RTPのためにプロフィールを補助しました。
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed in ROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression making use of this header-free packet.
このドキュメントはIP/UDP/RTP(インターネットのリアルプロトコル/ユーザー・データグラム・プロトコル/タイムのTransportプロトコル)パケットの圧縮のためのROHC(強健なHeader Compression)プロフィールを定義します、下層によって提供された、ほとんどのパケットのために最適の操作の間、ヘッダーを完全に排除することによって圧縮効率を増加させた機能性を利用して。 プロフィールは拡大としてROHC RTPプロフィールに造られます。 それは、ROHCで必要である追加メカニズムを定義して、透明を保証するという補助層に関する要件を述べて、この無ヘッダーのパケットを利用する圧縮と減圧に一般的な論理を指定します。
Table of Contents
目次
1. Introduction....................................................2
2. Terminology.....................................................4
3. Overview of the Link-Layer Assisted Profile.....................5
3.1. Providing Packet Type Identification.....................6
3.2. Replacing the Sequence Number............................6
3.3. CRC Replacement..........................................7
3.4. Applicability of This Profile............................7
4. Additions and Exceptions Compared to ROHC RTP...................8
4.1. Additional Packet Types..................................8
4.1.1. No-Header Packet (NHP)..........................8
4.1.2. Context Synchronization Packet (CSP)............8
4.1.3. Context Check Packet (CCP)......................9
1. 序論…2 2. 用語…4 3. リンクレイヤの概観はプロフィールを補助しました…5 3.1. パケットを提供して、識別をタイプしてください…6 3.2. 一連番号を置き換えます…6 3.3. CRC交換…7 3.4. このプロフィールの適用性…7 4. 追加と例外はROHC RTPと比較されました…8 4.1. 追加パケットはタイプされます…8 4.1.1. ヘッダーがないパケット(NHP)…8 4.1.2. 文脈同期パケット(CSP)…8 4.1.3. 文脈チェックパケット(CCP)…9
Jonsson, et. al Standards Track [Page 1] RFC 3242 A Link-Layer Assisted ROHC RTP April 2002
etイェンソン、アルStandards Track[1ページ]RFC3242A Link-層のAssisted ROHC RTP2002年4月
4.2. Interfaces Towards the Assisting Layer..................11
4.2.1. Interface, Compressor to Assisting Layer.......11
4.2.2. Interface, Assisting Layer to Decompressor.....12
4.3. Optimistic Approach Agreement...........................13
4.4. Fast Context Initialization, IR Redefinition............13
4.5. Feedback Option, CV-REQUEST.............................14
4.6. Periodic Context Verification...........................15
4.7. Use of Context Identifier...............................15
5. Implementation Issues..........................................15
5.1. Implementation Parameters and Signals...................15
5.1.1. Implementation Parameters at the Compressor....16
5.1.2. Implementation Parameters at the Decompressor..17
5.2. Implementation over Various Link Technologies...........18
6. IANA Considerations............................................18
7. Security Considerations........................................18
8. Acknowledgements...............................................18
9. References.....................................................19
10. Authors' Addresses.............................................20
11. Full Copyright Statement.......................................21
4.2. 補助に向かったインタフェースは層にされます…11 4.2.1. インタフェース、補助へのコンプレッサーは層にされます…11 4.2.2. 減圧装置に層を補助して、連結してください…12 4.3. 楽観的なアプローチ協定…13 4.4. 速い文脈初期設定、IR Redefinition…13 4.5. フィードバックオプション、CV-要求…14 4.6. 周期的な文脈検証…15 4.7. 文脈識別子の使用…15 5. 実現問題…15 5.1. 実現パラメタと信号…15 5.1.1. コンプレッサーの実現パラメタ…16 5.1.2. 減圧装置における実現パラメタ。17 5.2. 様々なリンク技術の上の実現…18 6. IANA問題…18 7. セキュリティ問題…18 8. 承認…18 9. 参照…19 10. 作者のアドレス…20 11. 完全な著作権宣言文…21
1. Introduction
1. 序論
Header compression is a technique used to compress and transparently decompress the header information of a packet on a per-hop basis, utilizing redundancy within individual packets and between consecutive packets within a packet stream. Over the years, several protocols [VJHC, IPHC] have been developed to compress the network and transport protocol headers [IPv4, IPv6, UDP, TCP], and these schemes have been successful in improving efficiency over many wired bottleneck links, such as modem connections over telephone networks. In addition to IP, UDP, and TCP compression, an additional compression scheme called Compressed RTP [CRTP] has been developed to further improve compression efficiency for the case of real-time traffic using the Real-Time Transport Protocol [RTP].
ヘッダー圧縮は1ホップあたり1個のベースのパケットに関するヘッダー情報を圧縮して、透明に減圧するのに使用されるテクニックです、パケットの流れの中で個々のパケットと連続したパケットの間の冗長を利用して。 数年間、いくつかのプロトコル[VJHC、IPHC]がネットワークとトランスポート・プロトコルヘッダー[IPv4、IPv6、UDP、TCP]を圧縮するために開発されています、そして、これらの計画は多くのワイヤードなボトルネックリンクの上に能率を増進するのに成功しています、電話網の上のモデム接続などのように。 IP、UDP、およびTCP圧縮に加えて、リアルタイムの交通に関するケースのためにレアル-時間Transportプロトコル[RTP]を使用することで圧縮効率をさらに高めるためにCompressed RTP[CRTP]と呼ばれる追加圧縮技術を開発してあります。
The schemes mentioned above have all been designed taking into account normal assumptions about link characteristics, which traditionally have been based on wired links only. However, with an increasing number of wireless links in the Internet paths, these assumptions are no longer generally valid. In wireless environments, especially wide coverage cellular environments, relatively high error rates are tolerated in order to allow efficient usage of the radio resources. For real-time traffic, which is more sensitive to delays than to errors, such operating conditions will be norm over, for example, 3rd generation cellular links, and header compression must therefore tolerate packet loss. However, with the previously mentioned schemes, especially for real-time traffic compressed by CRTP, high error rates have been shown to significantly degrade
前記のように計画は、ワイヤードなリンクだけに伝統的に基づいたリンクの特性に関する通常の仮定を考慮に入れながら、すべて設計されています。 しかしながら、一般に、増加する数の無線のリンクがインターネット経路にある状態で、これらの仮定はもう有効ではありません。 無線の環境、特に広い適用範囲セル環境で、比較的高い誤り率は、ラジオリソースの効率的な用法を許容するために許容されます。 そのような運転条件は例えば、3番目の世代のセルリンクの上にリアルタイムの交通への、標準になるでしょう、そして、したがって、ヘッダー圧縮はパケット損失を黙認しなければなりません。(交通は誤りより遅れに敏感です)。 しかしながら、以前に言及された計画で、特にCRTPによって圧縮されたリアルタイムの交通において、高い誤り率は、かなり退行するために示されました。
Jonsson, et. al Standards Track [Page 2] RFC 3242 A Link-Layer Assisted ROHC RTP April 2002
etイェンソン、アルStandards Track[2ページ]RFC3242A Link-層のAssisted ROHC RTP2002年4月
header compression performance [CRTPC]. This problem was the driving force behind the creation of the RObust Header Compression (ROHC) WG in the IETF.
ヘッダー圧縮性能[CRTPC]。 この問題はIETFでのRObust Header Compression(ROHC)WGの創造の後ろの原動力でした。
The ROHC WG has developed a header compression framework on top of which profiles can be defined for different protocol sets, or for different compression strategies. Due to the limited packet loss robustness of CRTP, and the demands of the cellular industry for an efficient way of transporting voice over IP over wireless, the main focus of ROHC has so far been on compression of IP/UDP/RTP headers, which are generous in size, especially compared to the payloads often carried by packets with such headers.
ROHC WGは上異なったプロトコルセット、または異なった圧縮戦略のためにプロフィールを定義できるヘッダー圧縮枠組みを開発しました。 CRTPの限られたパケット損失丈夫さ、および無線電信の上でIPの上で声を輸送する効率的な方法のためのセル産業の要求のために、今までのところ、サイズで豊富なIP/UDP/RTPヘッダーの圧縮にはROHCの主な焦点がありました、そのようなヘッダーと共にパケットによってしばしば運ばれたペイロードと特に比べて。
ROHC RTP has become a very efficient, robust and capable compression scheme, able to compress the headers down to a total size of one octet only. Also, transparency is guaranteed to an extremely great extent even when residual bit errors are present in compressed headers delivered to the decompressor. The requirements for RTP compression [RTP-REQ], defined by the WG before and during the development process, have thus been fulfilled.
ROHC RTPは非常に効率的で、強健でできる圧縮技術になりました、ヘッダーを1つの八重奏だけの総サイズまで圧縮できます。 また、残りの噛み付いている誤りが減圧装置に届けられた圧縮されたヘッダーに存在してさえいるとき、透明は非常に大きい程度まで保証されます。 その結果、開発過程の前と開発過程間にWGによって定義されたRTP圧縮[RTP-REQ]のための要件が実現しました。
As mentioned above, the 3rd generation cellular systems, where IP will be used end-to-end, have been one of the driving forces behind ROHC RTP, and the scheme has been designed to also suit new cellular air interfaces, such as WCDMA, making it possible to run even speech services with spectrum efficiency insignificantly lower than for existing one-service circuit switched solutions [VTC2000]. However, other air interfaces such as those based on GSM and IS-95 will also be used in all-IP networks, with further implications for the header compression issue. These older air interfaces are less flexible, with radio bearers optimized for specific payload sizes. This means that not even a single octet of header can be added without using the next higher fixed packet size supported by the link, something which is obviously very costly. For the already deployed speech vocoders, the spectrum efficiency over these links will thus be low compared to existing circuit switched solutions. To achieve high spectrum efficiency overall with any application, more flexible air interfaces must be deployed, and then the ROHC RTP scheme will perform excellently, as shown for WCDMA [MOMUC01]. However, for deployment reasons, it is however important to also provide a suitable header compression strategy for already existing vocoders and air interfaces, such as for GERAN and for CDMA2000, with minimal effects on spectral efficiency.
以上のように、3番目の世代セルラ方式はIPが終わりから中古の終わりになるところのROHC RTPの後ろの原動力の1つです、そして、計画はまた、新しいセル空気インタフェースに合うように設計されています、WCDMAなどのように、スペクトル効率が1サービスのサーキットが存在するように、解決策[VTC2000]を切り換えたより無意味に低い状態でスピーチサービスさえ走らせるのを可能にして。 そして、しかしながら、他の空気がGSMに基づくものなどのように連結する、-95である、また、オールIPネットワークに使用されるでしょう、ヘッダー圧縮問題のためのさらなる含意で。 ラジオ運搬人が特定のペイロードサイズのために最適化されている状態で、これらのより古い空気インタフェースはそれほどフレキシブルではありません。 これは、リンク明らかに非常に(何か高価なもの)によって支持された次の、より高い固定パケットサイズを使用しないでヘッダーの1つの八重奏もさえ加えることができないことを意味します。 その結果、既存のサーキット切り換えられた解決策と比べて、これらのリンクの上のスペクトル効率は既に配備されたスピーチボコーダに関しては低くなるでしょう。 どんなアプリケーションでも全体的に見て高いスペクトル効率を達成するために、よりフレキシブルな空気インタフェースを配備しなければなりません、そして、次に、ROHC RTP計画はすばらしく働くでしょう、WCDMA[MOMUC01]のために示されるように。 しかしながらまた、既に存在するための適当なヘッダー圧縮戦略にボコーダを提供して、GERANやCDMA2000などのインタフェースを空気に提供するためにどんなに重要であってもそれは展開理由でです、スペクトル効率への最小量の効果で。
This document defines a new link-layer assisted ROHC RTP profile extending ROHC RTP (profile 0x0001) [ROHC], compliant with the ROHC 0-byte requirements [0B-REQ]. The purpose of this new profile is to provide a header-free packet format that, for a certain application
このドキュメントは補助ROHC RTPの新しいプロフィール広がりROHC RTP(プロフィール0x0001)[ROHC]リンクレイヤを定義します、ROHCの0バイトの要件[0B-REQ]で、言いなりになります。 この新しいプロフィールの目的はあるアプリケーションのために無ヘッダーのパケット・フォーマットにそれを提供することです。
Jonsson, et. al Standards Track [Page 3] RFC 3242 A Link-Layer Assisted ROHC RTP April 2002
etイェンソン、アルStandards Track[3ページ]RFC3242A Link-層のAssisted ROHC RTP2002年4月
behavior, can replace a majority of the 1-octet header ROHC RTP packets during normal U/O-mode operation, while still being fully transparent and complying with all the requirements of ROHC RTP [RTP-REQ]. For other applications, compression will be carried out as with normal ROHC RTP.
振舞い、まだ完全に透明である間の正常なO U/モード操作とROHC RTP[RTP-REQ]のすべての要件に従っている間、1八重奏のヘッダーROHC RTPパケットの大部分を取り替えることができます。 他のアプリケーションにおいて、圧縮が正常なROHC RTPの場合行われるでしょう。
To completely eliminate the compressed header, all functionality normally provided by the 1-octet header has to be provided by other means, typically by utilizing functionality provided by the lower layers and sacrificing efficiency for less frequently occurring larger compressed headers. The latter is not a contradiction since the argument for eliminating the last octet for most packets is not overall efficiency in general. It is important to remember that the purpose of this profile is to provide efficient matching of existing applications to existing link technologies, not efficiency in general. The additional complexity introduced by this profile, although minimized by a tight integration with already existing ROHC functionality, implies that it should therefore only be used to optimize performance of specific applications over specific links.
圧縮されたヘッダーを完全に排除するために、他の手段で通常、1八重奏のヘッダーによって提供されたすべての機能性を提供しなければなりません、通常、下層によって提供されて、より少ない頻繁に起こっているより大きい圧縮されたヘッダーのために効率を犠牲にしながら機能性を利用することによって。 後者は、ほとんどのパケットのための最後の八重奏を排除するための議論が一般に、全体的効率でないので、矛盾ではありません。 忘れずに一般に、効率ではなく、既存のリンク技術に既存のアプリケーションの効率的なマッチングをこのプロフィールの目的がことである提供するのは重要です。 既に既存のROHCの機能性できつい統合で最小にされますが、このプロフィールによって導入された追加複雑さは、したがって、それが特定のリンクの上の特定のアプリケーションの性能を最適化するのに使用されるだけであるべきであるのを含意します。
When implementing this profile over various link technologies, care must be taken to guarantee that all the functionality needed is provided by ROHC and the lower layers together. Therefore, additional documents should specify how to incorporate this profile on top of various link technologies.
様々なリンク技術の上でこのプロフィールを実行するとき、機能性が必要としたすべてがROHCと下層によって一緒に提供されるのを保証するために注意しなければなりません。 したがって、追加ドキュメントは様々なリンク技術の上にこのプロフィールを組み込む方法を指定するはずです。
2. Terminology
2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
CCP Context Check Packet CRC Cyclic Redundancy Check CSP Context Synchronization Packet LLA Link Layer Assisted ROHC RTP profile NHP No Header Packet ROHC RObust Header Compression RHP ROHC Header Packet (a non-NHP packet, i.e., RRP, CSP or CCP) RRP ROHC RTP Packet as defined in [ROHC, profile 0x0001]
中で定義されるHeader Packet ROHC RObust Header Compression RHP ROHC Header Packet(すなわち、非NHPパケット、RRP、CSPまたはCCP)のCCP Context Check Packet CRC Cyclic Redundancy Check CSP Context Synchronization Packet LLA Link Layer Assisted ROHC RTPプロフィールNHPノーRRP ROHC RTP Packet[ROHC、プロフィール0x0001]
Assisting layer
補助層
"Assisting layer" refers to any entity implementing the interface
to ROHC (section 4.2). It may, for example, refer to a sub-layer
used to adapt the ROHC implementation and the physical link layer.
This layer is assumed to have knowledge of the physical layer
synchronization.
「層を補助します」はROHC(セクション4.2)にインタフェースを実行するどんな実体も示します。 例えば、それはROHC実現を適合させるのに使用される副層と物理的なリンクレイヤについて言及するかもしれません。 この層には物理的な層の同期に関する知識があると思われます。
Jonsson, et. al Standards Track [Page 4] RFC 3242 A Link-Layer Assisted ROHC RTP April 2002
etイェンソン、アルStandards Track[4ページ]RFC3242A Link-層のAssisted ROHC RTP2002年4月
Compressing side
側を圧縮します。
"Compressing side" refers to the combination of the header
compressor, operating with the LLA profile, and its associated
assisting layer.
「側を圧縮します」はヘッダーコンプレッサーの組み合わせ、LLAプロフィールによる操作、およびその関連補助層を示します。
Lower layers
下層
"Lower layers" in this document refers to entities located below
ROHC in the protocol stack, including the assisting layer.
補助層を含んでいて、「下層」は本書ではプロトコル・スタックにROHCの下に位置する実体を示します。
ROHC RTP
ROHC RTP
"ROHC RTP" in this document refers to the IP/UDP/RTP profile
(profile 0x0001) as defined in [ROHC].
"ROHC RTP"は本書では[ROHC]で定義されるIP/UDP/RTPプロフィール(プロフィール0x0001)を示します。
3. Overview of the Link-Layer Assisted Profile
3. リンクレイヤの補助プロフィールの概観
The ROHC IP/UDP/RTP profile defined in this document, profile 0x0005 (hex), is designed to be used over channels that have been optimized for specific payload sizes and therefore cannot efficiently accommodate header information when transmitted together with payloads corresponding to these optimal sizes.
プロフィールが本書では定義したROHC IP/UDP/RTP(プロフィール0x0005(魔法をかける))は特定のペイロードサイズのために最適化されたチャンネルの上に使用されるように設計されていて、したがって、これらの最適規模に対応するペイロードと共に伝えられる場合、効率的にヘッダー情報に対応できません。
The LLA profile extends, and thus also inherits all functionality from, the ROCH RTP profile by defining some additional functionality and an interface from the ROHC component towards an assisting lower layer.
補助下層に向かったプロフィールが広げていて、その結果またすべての機能性を引き継ぐLLA、何らかの追加機能性を定義するのによるROCH RTPプロフィール、およびROHCの部品からのインタフェース。
+---------------------------------------+
| |
The LLA | ROHC RTP, |
profile | Profile #1 +-----------------+
| | LLA Additions |
+---------------------+-----------------+
+---------------------------------------+ | | LLA| ROHC RTP| プロフィール| プロフィール#1+-----------------+ | | LLA追加| +---------------------+-----------------+
By imposing additional requirements on the lower layers compared to [ROHC], it is possible to infer the information needed to maintain robust and transparent header compression even though the headers are completely eliminated during most of the operation time.
[ROHC]と比べて、追加要件を下層に課すことによって、ヘッダーが演算時間の大部分完全に排除されますが、強健でわかりやすいヘッダー圧縮を維持するのに必要である情報を推論するのは可能です。
Basically, what this profile does is to replace the smallest and most frequent ROHC U/O-mode headers with a no-header format, for which the header functionality must be provided by other means.
基本的に、このプロフィールがすることは最も小さくて最も頻繁なO ROHC U/モードヘッダーをどんなヘッダー形式にも取り替えることになっていません。(それにおいて他の手段でヘッダーの機能性を提供しなければなりません)。
Jonsson, et. al Standards Track [Page 5] RFC 3242 A Link-Layer Assisted ROHC RTP April 2002
etイェンソン、アルStandards Track[5ページ]RFC3242A Link-層のAssisted ROHC RTP2002年4月
Smallest header in Smallest header in
ROHC RTP (profile #1) LLA (profile #5)
+--+--+--+--+--+--+--+--+ ++
| 1 octet | -----> || No Header
+--+--+--+--+--+--+--+--+ ++
|
| Header field functionality
+-------------------> provided by other means
ROHC RTP(プロフィール#1)LLA(プロフィール#5)+--+--+--+--+--+--+--+--+ + +のSmallestヘッダーで最も小さいヘッダー| 1つの八重奏| ----->|| ヘッダーがありません+--+--+--+--+--+--+--+--+ + +| | ヘッダーフィールドの機能性+-------------------他の手段で提供された>。
The fields present in the ROHC RTP headers for U/O-mode PT0 are the packet type identifier, the sequence number and the CRC. The subsequent sections elaborate more on how the functionality of these fields is replaced for NHP.
O U/モードPT0のためのROHC RTPヘッダーの現在の分野は、パケットタイプ識別子と、一連番号とCRCです。 その後のセクションはNHPのためにどうこれらの分野の機能性を取り替えるかをもう少し詳しく説明します。
3.1. Providing Packet Type Identification
3.1. パケットタイプ確認を提供します。
All ROHC headers carry a packet type identifier, indicating to the decompressor how the header should be interpreted. This is a function that must be provided by some means in 0-byte header compression. ROHC RTP packets with compressed headers will be possible to distinguish thanks to the packet type identifier, but a mechanism is needed to separate packets with a header from packets without a header. This function MUST therefore be provided by the assisting layer in one way or another.
ヘッダーがどう解釈されるべきであるかを減圧装置に示して、すべてのROHCヘッダーがパケットタイプ識別子を運びます。 これはどうでも0バイトのヘッダー圧縮に提供しなければならない機能です。 圧縮されたヘッダーがあるROHC RTPパケットはパケットタイプ識別子のおかげで区別するのにおいて可能になるでしょうが、メカニズムが、ヘッダーと共にパケットからヘッダーなしでパケットを分離するのに必要です。 したがって、補助層のそばでどうかしてこの機能を提供しなければなりません。
3.2. Replacing the Sequence Number
3.2. 一連番号を置き換えます。
From the sending application, the RTP sequence number is increased by one for each packet sent. The purpose of the sequence number is to cope with packet reordering and packet loss. If reordering or loss has occurred before the transmission point, if needed the compressing side can easily avoid problems by not allowing the use of a header- free packet.
送付アプリケーションから、RTP一連番号は送られた各パケットあたり1つ増加します。 一連番号の目的はパケット再命令とパケット損失に対処することです。 再命令か損失がトランスミッションポイントの前に発生したなら、必要であるなら、圧縮側は、ヘッダーの結合していないパケットの使用を許さないことによって、容易に問題を避けることができます。
However, at the transmission point, loss or reordering that may occur over the link can not be anticipated and covered for. Therefore, for NHP the assisting layer MUST guarantee in-order delivery over the link (already assumed by [ROHC]) and at the receiving side it MUST provide an indication for each packet loss over the link. This is basically the same principle as the VJ header compression [VJHC] relies on.
しかしながら、トランスミッションポイントでは、リンクの上に発生するかもしれない損失か再命令は、予期して、守ることができません。 したがって、NHPに関して、補助層は、リンクの上の各パケット損失のための指示を提供しなければならないのをリンク([ROHC]によって既に想定される)と受信側のオーダーにおける配送に保証しなければなりません。 これは基本的に圧縮[VJHC]が当てにするVJヘッダーと同じ原則です。
Note that guaranteeing in-order delivery and packet loss indication over the link not only makes it possible to infer the sequence number information, but also supersedes the main function of the CRC, which normally takes care of errors due to long link losses and bit errors in the compressed sequence number.
圧縮された一連番号における長いリンクの損失と噛み付いている誤りのためリンクの上のオーダーにおける配送とパケット損失指示を保証すると通常、誤りの世話をするCRCの主な機能が一連番号情報を推論するのを可能にするだけではなく、取って代わられもすることに注意してください。
Jonsson, et. al Standards Track [Page 6] RFC 3242 A Link-Layer Assisted ROHC RTP April 2002
etイェンソン、アルStandards Track[6ページ]RFC3242A Link-層のAssisted ROHC RTP2002年4月
3.3. CRC Replacement
3.3. CRC交換
All context updating RRP packets carry a CRC calculated over the uncompressed header. The CRC is used by the decompressor to verify that the updated context is correct. This verification serves three purposes in U/O-mode:
RRPパケットをアップデートするすべての文脈が解凍されたヘッダーの上に計算されたCRCを運びます。 CRCは減圧装置によって使用されて、アップデートされた文脈が正しいことを確かめます。 この検証はO U/モードによる3つの目的に役立ちます:
1) Detection of longer losses than can be covered by the sequence
number LSBs
2) Protection against failures caused by residual bit errors in
compressed headers
3) Protection against faulty implementations and other causes of
error
1) 一連番号LSBs2)で覆うことができるより長い損失の検出 残差によって引き起こされた失敗に対する保護は圧縮されたヘッダー3)で誤りに噛み付きました。 不完全な実現と誤りの他の原因に対する保護
Since this profile defines an NHP packet without this CRC, care must be taken to fulfill these purposes by other means, when an NHP is used as a replacement for a context updating packet. Detection of long losses (1) is already covered since the assisting layer MUST provide indication of all packet losses. Furthermore, the NHP packet has one important advantage over RHP packets in that residual bit errors (2) cannot damage a header that is not even sent.
このプロフィールがこのCRCなしでNHPパケットを定義するので、他の手段でこれらの目的を実現させるために注意しなければなりません、NHPがパケットをアップデートする文脈に交換として使用されるとき。 補助層がすべてのパケット損失のしるしを供給しなければならないので、長い損失(1)の検出は既にカバーされています。 その上、残りの噛み付いている誤り(2)が送られてさえいないヘッダーを破損しない場合があるので、NHPパケットにはRHPパケットより1つの重要な利点があります。
It is thus reasonable to assume that compression and decompression transparency can be assured with high confidence even without a CRC in header-free packets. However, to provide additional protection against damage propagation due to undetected residual bit errors in context updating packets (2) or other unexpected errors (3), periodic context verifications SHOULD be performed (see section 4.6).
その結果、無ヘッダーのパケットで高い自信をもってCRCがなくても圧縮と減圧透明を保証できると仮定するのは妥当です。 しかしながら、パケット(2)か他の予期せぬエラー(3)、周期的な文脈検証SHOULDをアップデートしながら状況内において非検出された残りの噛み付いている誤りによる損害伝播に対する追加保護を提供するには、実行されてください(セクション4.6を見てください)。
3.4. Applicability of This Profile
3.4. このプロフィールの適用性
The LLA profile can be used with any link technology capable of providing the required functionality described in previous sections. Whether LLA or ROHC RTP should be implemented thus depends on the characteristics of the link itself. For most RTP packet streams, LLA will work exactly as ROHC RTP, while it will be more efficient for packet streams with certain characteristics. LLA will never be less efficient than ROHC RTP.
どんなリンク技術もできていた状態で、前項で説明された必要な機能性を提供するのについてLLAプロフィールを使用できます。 LLAかROHC RTPがこのようにして実行されるべきであるかどうかがリンク自体の特性に依存します。 ほとんどのRTPパケットの流れのために、LLAはちょうどROHC RTPとして働くでしょう、ある特性があるパケットの流れには、より効率的になるでしょうが。 LLAはROHC RTPほど決して効率的でなくならないでしょう。
Note as well that LLA, like all other ROHC profiles, is fully transparent to any packet stream reaching the compressor. LLA does not make any assumptions about the packet stream but will perform optimally for packet streams with certain characteristics, e.g., synchronized streams exactly timed with the assisting link over which the LLA profile is implemented.
また、LLAが他のすべてのROHCプロフィールのようにコンプレッサーに達するどんなパケットの流れにも完全に透明であることに注意してください。 LLAはある特性(例えばまさにLLAプロフィールが実行される補助リンクで調節された連動している流れ)でパケットの流れに関して少しの仮定もしませんが、パケットの流れのために最適に働くでしょう。
Jonsson, et. al Standards Track [Page 7] RFC 3242 A Link-Layer Assisted ROHC RTP April 2002
etイェンソン、アルStandards Track[7ページ]RFC3242A Link-層のAssisted ROHC RTP2002年4月
The LLA profile is obviously not applicable if the UDP checksum (2 bytes) is enabled, which is always the case for IPv6/UDP. For IPv4/UDP, the sender may choose to disable the UDP checksum.
UDPチェックサム(2バイト)(いつもIPv6/UDPのためのケースである)が可能にされるなら、LLAプロフィールは明らかに適切ではありません。 IPv4/UDPのために、送付者は、UDPチェックサムを無効にするのを選ぶかもしれません。
4. Additions and Exceptions Compared to ROHC RTP
4. ROHC RTPと比較された追加と例外
4.1. Additional Packet Types
4.1. 追加パケットタイプ
The LLA profile defines three new packet types to be used in addition to the RRP packet types defined by [ROHC]. The following sections describe these packet types and their purpose in detail.
LLAプロフィールは、[ROHC]によって定義されたRRPパケットタイプに加えて使用されるために3つの新しいパケットタイプを定義します。 以下のセクションは詳細にこれらのパケットタイプと彼らの目的について説明します。
4.1.1. No-Header Packet (NHP)
4.1.1. ヘッダーがないパケット(NHP)
A No-Header Packet (NHP), i.e., a packet consisting only of a payload, is defined and MAY be used when only sequencing must be conveyed, i.e., when all header fields are either unchanged or follow the currently established change pattern. In addition, there are some considerations for the use of the NHP (see 4.3, 4.5 and 4.6). An LLA compressor is not allowed to deliver NHP packets when operating in R-mode.
配列だけを運ばなければならないとき、ヘッダーがないPacket(NHP)(すなわち、ペイロードだけから成るパケット)は定義されて、使用されるかもしれません、すなわち、すべてのヘッダーフィールドが変わりがないか、または現在確立した変化パターンに従うと。 さらに、NHPの使用のためのいくつかの問題があります(4.3、4.5、および4.6を見てください)。 R-モードで作動するとき、LLAコンプレッサーはパケットをNHPに渡すことができません。
The assisting layer MAY send the NHP for RTP SN = X only if an NHP was delivered by the LLA compressor AND the assisting layer can guarantee that the decompressor will infer the proper sequencing for this NHP. This guarantee is based on the confidence that the decompressor
LLAコンプレッサーでNHPを届けた場合にだけ、補助層はRTP SN=XのためにNHPを送るかもしれません、そして、補助層は減圧装置がこのNHPのための適切な配列を推論するのを保証できます。 この保証が信用に基づいている、それ、減圧装置
a) has the means to infer proper sequencing for the packet
corresponding to SN = X-1, AND
b) has either received a loss indication or the packet itself for the
packet corresponding to SN = X-1.
a) SN=X-1、およびb)に対応するパケットのための適切な配列を推論する手段が損失指示を受けたか、またはSNに対応するパケットのためのパケット自体はX-1と等しいです。
Updating properties: NHP packets update context (RTP Sequence Number).
特性をアップデートします: NHPパケットは文脈(RTP Sequence Number)をアップデートします。
4.1.2. Context Synchronization Packet (CSP)
4.1.2. 文脈同期パケット(CSP)
The case where the packet stream overruns the channel bandwidth may lead to data being discarded, which may result in decompressor context invalidation. It might therefore be beneficial to send a packet with only the header information and discard the payload. This would be helpful to maintain synchronization of the decompressor context, while efficiently using the available bandwidth.
パケットの流れがチャンネル帯域幅を走らせるこの件は捨てられるデータにつながるかもしれません。(データは減圧装置文脈無効にするのをもたらすかもしれません)。 したがって、ヘッダー情報だけがあるパケットを送って、ペイロードを捨てるのは有益であるかもしれません。 これは、減圧装置文脈の同期を維持するために効率的に利用可能な帯域幅を使用している間、役立っているでしょう。
Jonsson, et. al Standards Track [Page 8] RFC 3242 A Link-Layer Assisted ROHC RTP April 2002
etイェンソン、アルStandards Track[8ページ]RFC3242A Link-層のAssisted ROHC RTP2002年4月
This case can be handled with the Context Synchronization Packet (CSP), which has the following format:
Context Synchronization Packet(CSP)と共に本件を扱うことができます:(Context Synchronization Packetは以下の形式を持っています)。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 1 0 | Packet type identifier
+===+===+===+===+===+===+===+===+
: ROHC header without padding :
: see [ROHC, section 5.7] :
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 0 1 0 | パケットタイプ識別子+===+===+===+===+===+===+===+===+ : 詰め物のないROHCヘッダー: : [ROHC、セクション5.7]は見ます: +---+---+---+---+---+---+---+---+
Updating properties: CSP maintains the updating properties of the ROHC header it carries.
特性をアップデートします: CSPはそれが運ぶROHCヘッダーのアップデートの特性を維持します。
The CSP is defined by one of the unused packet type identifiers from ROHC RTP, carried in the one-octet base header. As for any ROHC packet, except the NHP, the packet may begin with ROHC padding and/or feedback. It may also carry context identification after the packet type identifier. It is possible to have two CID fields present, one after the packet type ID and one within the encapsulated ROHC header. If a decompressor receives a CSP with two non-equal CID values included, the packet MUST be discarded. ROHC segmentation may also be applied to the CSP.
CSPは未使用のパケットタイプ識別子の1つによって1八重奏のベースヘッダーで運ばれたROHC RTPから定義されます。 NHP以外のどんなROHCパケットに関しても、パケットはROHC詰め物、そして/または、フィードバックで始まるかもしれません。 また、それはパケットタイプ識別子の後まで文脈識別を運ぶかもしれません。 要約のROHCヘッダーの中にCID分野が提示する2、パケットタイプIDの後の1、および1つを持っているのは可能です。 2つの非等しいCID値が含まれている状態で減圧装置がCSPを受けるなら、パケットを捨てなければなりません。 また、ROHC分割はCSPに適用されるかもしれません。
Note that when the decompressor has received and processed a CSP, the packet (including any possible data following the CSP encapsulated compressed header) MUST be discarded.
減圧装置がCSPを受けて、処理したとき、パケット(CSPに続いて、どんな可能なデータも含んでいると、圧縮されたヘッダーはカプセルに入れられた)を捨てなければならないことに注意してください。
4.1.3. Context Check Packet (CCP)
4.1.3. 文脈チェックパケット(CCP)
A Context Check Packet (CCP), which does not carry any payload but only an optional CRC value in addition to the packet type identifier, is defined.
Context Check Packet(CCP)は定義されます。(Context Check Packetはどんなペイロードも運んで、パケットタイプ識別子に加えた任意のCRC値だけは運びません)。
The purpose of the CCP is to provide a useful packet that MAY be sent by a synchronized physical link layer in the case where data must be sent at fixed intervals, even if no compressed packet is available. Whether the CCP is sent over the link and delivered to the decompressor is decided by the assisting layer. The CCP has the following format:
CCPの目的は連動している物理的なリンクレイヤで定期的にデータを送らなければならない場合で送られるかもしれない役に立つパケットを提供することです、どんな圧縮されたパケットも利用可能でなくても。 CCPをリンクの上に送って、減圧装置に届けるかどうかが補助層によって決められます。 CCPには、以下の形式があります:
Jonsson, et. al Standards Track [Page 9] RFC 3242 A Link-Layer Assisted ROHC RTP April 2002
etイェンソン、アルStandards Track[9ページ]RFC3242A Link-層のAssisted ROHC RTP2002年4月
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 1 1 | Packet type identifier
+===+===+===+===+===+===+===+===+
| C | CRC |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 0 1 1 | パケットタイプ識別子+===+===+===+===+===+===+===+===+ | C| CRC| +---+---+---+---+---+---+---+---+
C: C = 0 indicates that the CRC field is not used;
C = 1 indicates that a valid CRC is present.
C: C=0は、CRC分野が使用されていないのを示します。 C=1は、有効なCRCが存在しているのを示します。
Updating properties: CCP packets do not update context.
特性をアップデートします: CCPパケットは文脈をアップデートしません。
The CCP is defined by one of the unused packet type identifiers from ROHC RTP, carried in the first octet of the base header. The first bit of the second octet, the C bit, indicates whether the CRC field is used or not. If C=1, the CRC field MUST be set to the 7-bits CRC calculated over the original uncompressed header defined in [ROHC section 5.9.2]. As for any ROHC packet, except NHP, the packet MAY begin with ROHC padding and/or carry context identification.
CCPは未使用のパケットタイプ識別子の1つによってベースヘッダーの最初の八重奏で運ばれたROHC RTPから定義されます。 2番目の八重奏の最初のビット(Cビット)は、CRC分野が使用されているかどうかを示します。 C=1であるなら、CRCが[ROHC部5.9の.2]で定義されたオリジナルの解凍されたヘッダーの上に計算した7ビットにCRC分野を設定しなければなりません。 NHP以外のどんなROHCパケットに関しても、パケットは、ROHCがそっと歩いていて始まる、そして/または、文脈識別を運ぶかもしれません。
The use of the CRC field to perform decompressor context verification is optional and is therefore a compressor implementation issue. However, a CCP MUST always be made available to the assisting layer.
減圧装置文脈検証を実行するCRC分野の使用は、任意であり、したがって、コンプレッサー導入問題です。 しかしながら、CCP MUST、いつも補助層に利用可能に作られてください。
If the assisting layer receives CCPs with the C-bit set (C=1) from the compressor, it MUST use the last CCP received if a CCP is to be sent, i.e., the CCP corresponding to the last non-CCP packet sent (NHP, RRP or CSP). An assisting layer MAY use the CCP for other purposes, such as signaling a packet loss before the link.
補助層がC-ビットセット(C=1)でコンプレッサーからCCPsを受けるなら、それはCCPを送るつもりであるなら受け取る最後のCCPを使用しなければなりません、すなわち、最後の非CCPパケットに対応するCCPが(NHP、RRPまたはCSP)を送りました。 補助層はリンクの前でパケット損失に合図などなどの他の目的にCCPを使用するかもしれません。
The decompressor is REQUIRED to handle a CCP received with the C bit set (C=1), indicating a valid CRC field, and perform context verification. The received CRC MUST then be applied to the last decompressed packet, unless a packet loss indication was previously received. Upon CRC failure, actions MUST be taken as specified in [ROHC, section 5.3.2.2.3]. A CCP received with C=0 MUST be ignored by the decompressor. The decompressor is not allowed to make any further interpretation of the CCP.
減圧装置は有効なCRC分野を示して、設定された(C=1)Cビットで受け取られたCCPを扱って、文脈検証を実行するREQUIREDです。 aパケット損失指示が以前に最後に減圧されたパケット受けられなかったなら適用されていて、その時、CRC MUSTを受けました。 ROHC、5.3を区分してください。指定されて、CRCの故障では、動作として取らなければならない、[.2 .2 .3]。 減圧装置でC=0で受け取られたCCPを無視しなければなりません。 減圧装置はCCPの少しのさらなる解釈もすることができません。
The use of CCP by an assisting layer is optional and depends on the characteristics of the actual link. Whether it is used or not MUST therefore be specified in link layer implementation specifications for this profile.
補助層のそばのCCPの使用は、任意であり、実際のリンクの特性に依存します。 したがって、このプロフィールのためのリンクレイヤ実現仕様でそれが使用されているかどうか指定しなければなりません。
Jonsson, et. al Standards Track [Page 10] RFC 3242 A Link-Layer Assisted ROHC RTP April 2002
etイェンソン、アルStandards Track[10ページ]RFC3242A Link-層のAssisted ROHC RTP2002年4月
4.2. Interfaces Towards the Assisting Layer
4.2. 補助に向かったインタフェースは層にされます。
This profile relies on the lower layers to provide the necessary functionality to allow NHP packets to be sent. This interaction between LLA and the assisting layer is defined as interfaces between the LLA compressor/decompressor and the LLA applicable link technology.
このプロフィールは、NHPパケットが送られるのを許容する必要な機能性を提供するために下層を当てにします。 LLAと補助層とのこの相互作用はLLAコンプレッサー/減圧装置とLLAの適切なリンク技術とのインタフェースと定義されます。
| |
+ +
+-------------------------+ +-------------------------+
| ROHC RTP HC | | ROHC RTP HD |
+-------------------------+ +-------------------------+
| LLA profile | | LLA profile |
+=========================+ +=========================+
| Interface | | Interface |
| ROHC to assisting layer | | Assisting layer to ROHC |
+=========================+ +=========================+
| Applicable | | Applicable |
| link technology | | link technology |
+=========================+ +=========================+
| |
+------>---- CHANNEL ---->-----+
| | + + +-------------------------+ +-------------------------+ | ROHC RTP HC| | ROHC RTP HD| +-------------------------+ +-------------------------+ | LLAプロフィール| | LLAプロフィール| +=========================+ +=========================+ | インタフェース| | インタフェース| | 補助へのROHCは層にします。| | ROHCに層を補助します。| +=========================+ +=========================+ | 適切| | 適切| | リンク技術| | リンク技術| +=========================+ +=========================+ | | +------>、-、-、-- チャンネル---->、-、-、-、--+
The figure above shows the various levels, as defined in [ROHC] and this document, constituting a complete implementation of the LLA profile. The figure also underlines the need for additional documents to specify how to implement these interfaces for a link technology for which this profile is relevant.
様々が平らにするショーを超えた[ROHC]とこのドキュメントで定義されるようにLLAプロフィールの完全な実現を構成する図。 また、図は追加ドキュメントがこのプロフィールが関連しているリンク技術のためにこれらのインタフェースを実行する方法を指定する必要性にアンダーラインを引きます。
This section defines the information to be exchanged between the LLA compressor and the assisting layer for this profile to operate properly. While it does define semantics, it does not specify how these interfaces are to be implemented.
このセクションは、このプロフィールが適切に操作するLLAコンプレッサーと補助層の間で交換するために情報を定義します。 意味論を定義しますが、それはこれらのインタフェースが実行されることになっている方法を指定しません。
4.2.1. Interface, Compressor to Assisting Layer
4.2.1. インタフェース、層を補助することへのコンプレッサー
This section defines the interface semantics between the compressor and the assisting layer, providing rules for packet delivery from the compressor.
このセクションはコンプレッサーと補助層の間のインタフェース意味論を定義します、コンプレッサーからパケット配信のための規則を提供して。
The interface defines the following parameters: RRP, RRP segmentation flag, CSP, CSP segmentation flag, NHP, and RTP Sequence Number. All parameters, except the NHP, MUST always be delivered to the assisting layer. This leads to two possible delivery scenarios:
インタフェースは以下のパラメタを定義します: RRP分割のCSP分割のRRP、旗、CSP、旗、NHP、およびRTP Sequence Number。 いつもNHP以外のすべてのパラメタを補助層に渡さなければなりません。 これは2つの可能な配送シナリオに通じます:
a. RRP, CSP, CCP, NHP and RTP Sequence Number are delivered, along
with the corresponding segmentation flags set accordingly.
a。 旗がそれに従って、設定する対応する分割と共にRRP、CSP、CCP、NHP、およびRTP Sequence Numberを届けます。
Jonsson, et. al Standards Track [Page 11] RFC 3242 A Link-Layer Assisted ROHC RTP April 2002
etイェンソン、アルStandards Track[11ページ]RFC3242A Link-層のAssisted ROHC RTP2002年4月
This corresponds to the case when the compressor allows sending of
an NHP packet, with or without segmentation being applied to the
corresponding RRP/CSP packets.
コンプレッサーでNHPパケットを発信させるとき、これはケースに対応しています、対応するRRP/CSPパケットに適用される分割のあるなしにかかわらず。
Recall that delivery of an NHP packet occurs when the ROHC RTP
compressor would have used a ROHC UO-0.
ROHC RTPコンプレッサーがROHC UO-0を使用しただろうというとき、NHPパケットの配送が起こったと思い出してください。
b. RRP, CSP, CCP and RTP Sequence Number are delivered, along with
the corresponding segmentation flags set accordingly.
b。 旗がそれに従って、設定する対応する分割と共にRRP、CSP、CCP、およびRTP Sequence Numberを届けます。
This corresponds to the case when the compressor does not allow
sending of an NHP packet. Segmentation might be applied to the
corresponding RRP and CSP packets.
コンプレッサーでNHPパケットを発信させないとき、これはケースに対応しています。 分割は対応するRRPとCSPパケットに適用されるかもしれません。
Segmentation may be applied independently to an RRP or a CSP packet if its size exceeds the largest value provided in the PREFERRED PACKET_SIZES list and if the LARGE_PACKET_ALLOWED parameter is set to false. The segmentation flags are explicitly stated in the interface definition to emphasize that the RRP and the CSP may be delivered by the compressor as segmented packets.
サイズがPREFERRED PACKET_SIZESリストに提供される中で最も大きい値を超えて、LARGE_PACKET_ALLOWEDパラメタが誤っているのに設定されるなら、分割は独自にRRPかCSPパケットに適用されるかもしれません。 分割旗は、RRPとCSPが区分されたパケットとしてコンプレッサーによって届けられるかもしれないと強調するためにインターフェース定義で明らかに述べられています。
The RTP SN MUST be delivered for each packet by the compressor to allow the assisting layer to maintain the necessary sequencing information.
RTP SN MUST、渡して、補助層はコンプレッサーによる各パケットで必要な配列情報を保守できてください。
4.2.2. Interface, Assisting Layer to Decompressor
4.2.2. 減圧装置に層を補助して、連結してください。
Here the interface semantics between the assisting layer and the decompressor are defined, providing simple rules for the delivery of received packets to the decompressor. The decompressor needs a way to distinguish NHP packets from RHP packets. Also, when receiving packets without a header, the decompressor needs a way to infer the sequencing information to keep synchronization between the received payload and the sequence information of the decompressed headers. To achieve this, the decompressor MUST receive the following from the assisting layer:
ここで、補助層と減圧装置の間のインタフェース意味論は定義されます、容認されたパケットの配送のための簡単な規則を減圧装置に提供して。 減圧装置はRHPパケットとNHPパケットを区別する方法を必要とします。 また、ヘッダーなしでパケットを受けるとき、減圧装置は減圧されたヘッダーの容認されたペイロードと系列情報の同期を間に置くために配列情報を推論する方法を必要とします。 これを達成するために、減圧装置は補助層から以下を受けなければなりません:
- an indication for each packet loss over the link between the
compressing and decompressing sides for CID=0
- the received packet together with an indication whether the packet
received is an NHP or not
- 圧縮とCID=0であることの側を減圧するとのリンクの上の各パケット損失のための指示--パケットが受信されたかどうかが、NHPであるという指示に伴う容認されたパケット
Note that the context is updated from a packet loss indication.
パケット損失指示から文脈をアップデートすることに注意してください。
Jonsson, et. al Standards Track [Page 12] RFC 3242 A Link-Layer Assisted ROHC RTP April 2002
etイェンソン、アルStandards Track[12ページ]RFC3242A Link-層のAssisted ROHC RTP2002年4月
4.3. Optimistic Approach Agreement
4.3. 楽観的なアプローチ協定
ROHC defines an optimistic approach for updates to reduce the header overhead. This approach is fully exploited in the Optimistic and Unidirectional modes of operation. Due to the presence of a CRC in all compressed headers, the optimistic approach is defined as a compressor issue only because the decompressor will always be able to detect an invalid context through the CRC verification.
アップデートがヘッダーオーバーヘッドを下げるように、ROHCは楽観的なアプローチを定義します。 このアプローチはOptimisticとUnidirectional運転モードで完全に利用されます。 すべての圧縮されたヘッダーでのCRCの存在への支払われるべきもの、単に減圧装置がCRC検証で無効の文脈をいつも検出できるので、楽観的なアプローチはコンプレッサー問題と定義されます。
However, no CRC is present in the NHP packet defined by the LLA profile. Therefore the loss of an RHP packet updating the context may not always be detected. To avoid this problem, the compressing and decompressing sides must agree on the principles for the optimistic approach, and the agreed principles MUST be enforced not only by the compressor but also by the transmitting assisting layer. If, for example, three consecutive updates are sent to convey a header field change, the decompressor must know this and invalidate the context in case of three or more consecutive physical packet losses. Note that the mechanism used to enforce the optimistic approach must be reinitialized if a new field change needs to be conveyed while the compressing side is already sending packets to convey non-linear context updates.
しかしながら、どんなCRCもLLAプロフィールによって定義されたNHPパケットに存在していません。 したがって、文脈をアップデートするRHPパケットの損失はいつも検出されるかもしれないというわけではありません。 この問題、圧縮、および減圧を避けるために、側は楽観的なアプローチのために原則に同意しなければなりません、そして、層を補助して、同意された原則はコンプレッサーで励行されるだけではなく、伝えることでも励行されなければなりません。 例えば、ヘッダーフィールド変化を運ぶために3つの連続したアップデートを送るなら、減圧装置は、3回以上の連続した物理的なパケット損失の場合にこれを知って、文脈を無効にしなければなりません。 新しい分野変化が、圧縮側が非線形の文脈最新版を伝えるために既にパケットを送る間、運ばれる必要があるなら楽観的なアプローチを実施するのに使用されるメカニズムを再初期化しなければならないことに注意してください。
An LLA decompressor MUST use the optimistic approach knowledge to detect possible context loss events. If context loss is suspected it MUST invalidate the context and not forward any packets before the context has been synchronized.
LLA減圧装置は、可能な文脈損失イベントを検出するのに楽観的なアプローチ知識を使用しなければなりません。 文脈の損失が疑われるなら、文脈が同期する前に、それは、文脈を無効にして、どんなパケットも進めてはいけません。
It is REQUIRED that all documents, describing how the LLA profile is implemented over a certain link technology, define how the optimistic approach is agreed between the compressing side and the decompressing side. It could be handled with a fixed principle, negotiation at startup, or by other means, but the method must be unambiguously defined.
LLAプロフィールが、あるリンク技術の上でどう実行されるかを説明して、すべてのドキュメントが圧縮側と減圧側の間で同意されていた状態で楽観的なアプローチがどうあるかを定義するのは、REQUIREDです。 固定原則、始動における、または、他の手段による交渉でそれを扱うことができましたが、明白に方法を定義しなければなりません。
4.4. Fast Context Initialization, IR Redefinition
4.4. 速い文脈初期設定、IR Redefinition
As initial IR packets might overrun the channel bandwidth and significantly delay decompressor context establishment, it might be beneficial to initially discard the payload. This allows state transitions and higher compression efficiency to be achieved with minimal delay.
初期のIRパケットがチャンネル帯域幅を走らせて、減圧装置文脈設立をかなり遅らせるかもしれないので、初めはペイロードを捨てるのは有益であるかもしれません。 これは、状態遷移と、より高い圧縮効率が最小量の遅れで達成されるのを許容します。
To serve this purpose, the D-bit from the basic structure of the ROHC RTP IR packet [ROHC section 5.7.7.1] is redefined for the LLA profile. For D=0 (no dynamic chain), the meaning of the D-bit is
この目的に役立つように、ROHC RTP IRパケット[ROHCセクション5.7.7.1]の基本構造からのD-ビットはLLAプロフィールのために再定義されます。 D=0(ダイナミックなチェーンがない)に関しては、D-ビットの意味はそうです。
Jonsson, et. al Standards Track [Page 13] RFC 3242 A Link-Layer Assisted ROHC RTP April 2002
etイェンソン、アルStandards Track[13ページ]RFC3242A Link-層のAssisted ROHC RTP2002年4月
extended to indicate that the payload has been discarded when assembling the IR packet. All other fields keep their meanings as defined for ROHC RTP.
IRパケットを組み立てるとき、ペイロードが捨てられたのを示すために、広げられます。 他のすべての分野がROHC RTPのために定義されるようにそれらの意味を保ちます。
The resulting structure, using small CIDs and CID=0, becomes:
結果として起こる構造(小さいCIDsを使用して、CID=0)は、なります:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 1 | 1 | 1 | 0 | D |
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| Static | variable length
| chain |
- - - - - - - - - - - - - - - -
| Dynamic | not present if D = 0
| chain | present if D = 1, variable length
- - - - - - - - - - - - - - - -
| Payload | not present if D = 0
| | present if D = 1, variable length
- - - - - - - - - - - - - - - -
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 1 | 1 | 1 | 1 | 1 | 0 | D| +---+---+---+---+---+---+---+---+ | プロフィール| 1 八重奏+---+---+---+---+---+---+---+---+ | CRC| 1 八重奏+---+---+---+---+---+---+---+---+ | 静電気| 可変長| チェーン| - - - - - - - - - - - - - - - - | 動力| どんなプレゼントもDであるなら0と等しくはありません。| チェーン| プレゼントはDであるなら1、可変長と等しいです--、--、--、--、--、--、--、--、--、--、--、--、--、--、--、-| 有効搭載量| どんなプレゼントもDであるなら0と等しくはありません。| | プレゼントはDであるなら1、可変長と等しいです--、--、--、--、--、--、--、--、--、--、--、--、--、--、--、-
D: D = 0 indicates that the dynamic chain is not present
and the payload has been discarded.
D: D=0は、ダイナミックなチェーンが存在していなくて、ペイロードが捨てられたのを示します。
After an IR packet with D=0 has been processed by the decompressor, the packet MUST be discarded.
D=0があるIRパケットが減圧装置によって処理された後に、パケットを捨てなければなりません。
4.5. Feedback Option, CV-REQUEST
4.5. フィードバックオプション、CV-要求
The CV-REQUEST option MAY be used by the decompressor to request an RRP or CSP for context verification. This option should be used if only NHP have been received for a long time and the context therefore has not been verified recently.
CV-REQUESTオプションは減圧装置によって使用されて、文脈検証のためにRRPかCSPを要求するかもしれません。 長い間NHPだけを受け取っていて、したがって、最近文脈について確かめていないなら、このオプションを使用するべきです。
+---+---+---+---+---+---+---+---+ | Opt Type = 8 | Opt Len = 0 | +---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+ | タイプ=8を選んでください。| レン=0を選んでください。| +---+---+---+---+---+---+---+---+
If the compressor receives a feedback packet with this option, the next packet compressed SHOULD NOT be delivered to the assisting layer as an NHP.
コンプレッサーがこのオプションでフィードバックパケットを受けるなら、次のパケットはSHOULD NOTを圧縮しました。NHPとして補助層に渡してください。
Jonsson, et. al Standards Track [Page 14] RFC 3242 A Link-Layer Assisted ROHC RTP April 2002
etイェンソン、アルStandards Track[14ページ]RFC3242A Link-層のAssisted ROHC RTP2002年4月
4.6. Periodic Context Verification
4.6. 周期的な文脈検証
As described in section 3.3, transparency is expected to be guaranteed by the functionality provided by the lower layers. This ROHC profile would therefore be at least as reliable as the older header compression schemes [VJHC, IPHC, CRTP], which do not make use of a header compression CRC. However, since ROHC RTP normally is extremely safe to use from a transparency point of view, it would be desirable to be able to achieve this with LLA also.
セクション3.3で説明されるように、下層によって提供された機能性によって透明が保証されると予想されます。 したがって、このROHCプロフィールは、より古いヘッダー圧縮がヘッダー圧縮CRCを利用しない[VJHC、IPHC、CRTP]を計画するのと少なくとも同じくらい信頼できるでしょう。 しかしながら、ROHC RTPが透明観点から使用するために通常非常に安全であるので、LLAと共にもこれを達成できるのは望ましいでしょう。
To provide an additional guarantee for transparency and also catch unexpected errors, such as errors due to faulty implementations, it is RECOMMENDED to periodically send context updating packets, even when the compressor logic allows NHP packets to be used.
それは文脈にパケットを定期的にアップデートさせるRECOMMENDEDです、追加保証を透明に提供して、また、不完全な実現のため誤りなどの予期せぬエラーを捕らえるならコンプレッサー論理が、NHPパケットが使用されるのを許容さえするとき。
4.7. Use of Context Identifier
4.7. 文脈識別子の使用
Since an NHP cannot carry a context identifier (CID), there is a restriction on how this profile may be used, related to context identification. Independent of which CID size has been negotiated, NHP packets can only be used for CID=0. If the decompressor receives an NHP packet, it can only belong to CID=0.
NHPが文脈識別子(CID)を運ぶことができないので、このプロフィールがどう使用されるかもしれないかに関する制限があります、文脈識別に関係づけられて。 どのCIDサイズが交渉されたかの如何にかかわらず、CID=0にNHPパケットを使用できるだけです。 減圧装置がNHPパケットを受けるなら、それはCID=0に属すことができるだけです。
Note that if multiple packet streams are handled by a compressor operating using LLA, the assisting layer must in case of physical packet loss be able to tell for which CID the loss occurred, or at least it MUST be able to tell if packets with CID=0 (packet stream with NHPs) have been lost.
複数のパケットの流れがLLA、補助層を使用することで作動するのがそうしなければならないコンプレッサーによって扱われるなら物理的なパケット損失の場合に損失がどのCIDに関して発生したか言うことができてください。さもないと、CID=0(NHPsとのパケットの流れ)があるパケットが失われたかどうか言うことができなければならないことに注意してください。
5. Implementation Issues
5. 導入問題
This document specifies mechanisms for the protocol and leaves details on the use of these mechanisms to the implementers. The present chapter aims to provide guidelines, ideas and suggestions for implementation of LLA.
このドキュメントは、プロトコルにメカニズムを指定して、これらの使用に関する詳細をimplementersへのメカニズムに残します。 現在の章は、LLAの実現のためのガイドライン、考え、および提案を提供することを目指します。
5.1. Implementation Parameters and Signals
5.1. 実現パラメタと信号
As described in [ROHC, section 6.3], implementations use parameters to set up configuration information and to stipulate how a ROHC implementation is to operate. The following parameters are additions, useful to LLA, to the parameter set defined for ROHC RTP implementations. Note that if the PREFERRED_PACKET_SIZES parameters defined here are used, they obsolete all PACKET_SIZE and PAYLOAD_SIZE parameters of ROHC RTP.
[ROHC、セクション6.3]で説明されるように、実現は設定情報をセットアップして、ROHC実現がどう作動するかことであることを規定するのにパラメタを使用します。 以下のパラメタはLLA、ROHC RTP実現のために定義されたパラメタセットの役に立つ追加です。 ここで定義されたPREFERRED_PACKET_SIZESパラメタが使用されているなら、ROHC RTPのすべてのPACKET_SIZEと有効搭載量_SIZEパラメタを時代遅れにすることに注意してください。
Jonsson, et. al Standards Track [Page 15] RFC 3242 A Link-Layer Assisted ROHC RTP April 2002
etイェンソン、アルStandards Track[15ページ]RFC3242A Link-層のAssisted ROHC RTP2002年4月
5.1.1. Implementation Parameters at the Compressor
5.1.1. コンプレッサーの実現パラメタ
ALWAYS_PAD -- value: boolean
ALWAYS_PAD--値: 論理演算子
This parameter may be set by an external entity to specify to the
compressor that every RHP packet MUST be padded with a minimum of
one octet ROHC padding.
外部実体によってこのパラメタが、最低1つの八重奏のROHCがそっと歩いていてあらゆるRHPパケットを水増ししなければならないとコンプレッサーに指定するように設定されるかもしれません。
The assisting layer MUST provide a packet type identification. If
no field is available for this purpose from the protocol at the
link layer, then a leading sequence may be used to distinguish RHP
packets from NHP packets. Although the use of a leading sequence
is obviously not efficient, since it sacrifices efficiency for RHP
packets, the efficiency loss should be insignificant because the
leading sequence applies only to packets with headers in order to
favor the use of packets without headers. If a leading sequence
is desired for RHP identification, the lower layer MAY use ROHC
padding for the leading sequence by setting the ALWAYS_PAD
parameter. Note that in such cases, possible collisions of the
padding with the NHP payload must be avoided.
補助層はパケットタイプ確認を提供しなければなりません。 どんな分野もこのためにリンクレイヤのプロトコルから利用可能でないなら、主な系列は、NHPパケットとRHPパケットを区別するのに使用されるかもしれません。 RHPパケットのために効率を犠牲にするので、主な系列の使用は明らかに効率的ではありませんが、主な系列がヘッダーなしでパケットの使用を支持するためにヘッダーと共にパケットだけに申し込まれるので、効率の損失はわずかであるべきです。 主な系列がRHP識別のために望まれているなら、下層は主な系列のためにALWAYS_PADパラメタを設定することによってそっと歩くROHCを使用するかもしれません。 そのような場合、NHPペイロードによる詰め物の可能な衝突を避けなければならないことに注意してください。
By default, this parameter is set to FALSE.
デフォルトで、このパラメタはFALSEに設定されます。
PREFERRED_PACKET_SIZES -- list of:
SIZE -- value: integer (octets)
RESTRICTED_TYPE -- values: [NHP_ONLY, RHP_ONLY, NO_RESTRICTION]
PREFERRED_PACKET_SIZES--以下のリスト SIZE--値: 整数(八重奏)RESTRICTED_TYPE--値: [唯一の_RHP NHP_だけ、いいえ、_制限]
This parameter set governs which packet sizes are preferred by the
assisting layer. If this parameter set is used, all RHP packets
MUST be padded to fit the smallest possible preferred size. If
the size of the unpadded packet (or, in the case of ALWAYS_PAD
being set, the packet with minimal one octet padding) is larger
than the maximal preferred packet size, the compressor has two
options. Either, it may deliver this larger packet with an
arbitrary size, or it may split the packet into several segments
using ROHC segmentation and pad each segment to one of the
preferred sizes. Which method to use depends on the value of the
LARGE_PACKETS_ALLOWED parameter below.
このパラメタセットは、どのパケットサイズが補助層によって好まれるかを治めます。 このパラメタセットが使用されているなら、可能な限りわずかな優先サイズに合うようにすべてのRHPパケットを水増ししなければなりません。 非水増しパケット(または最小量の1つの八重奏があるパケットがそっと歩いて、用意ができているALWAYS_PADの場合で)のサイズが最大限度の都合のよいパケットサイズより大きいなら、コンプレッサーには、2つのオプションがあります。 任意のサイズと共にこのより大きいパケットを届けるかもしれないか、それは、ROHC分割を使用することでパケットをいくつかのセグメントに分けて、優先サイズの1つに各セグメントを水増しするかもしれません。 どの方法を使用したらよいかは以下のLARGE_PACKETS_ALLOWEDパラメタの値に依存します。
NHP packets can be delivered to the lower layer only if the
payload size is part of the preferred packet size set.
Furthermore, if RESTRICTED_TYPE is set to one of NHP_ONLY or
RHP_ONLY for any of the preferred packet sizes, that size is
allowed only for packets of the specified type.
ペイロードサイズが都合のよいパケットサイズセットの一部である場合にだけNHPパケットを下層に届けることができます。 その上、RESTRICTED_TYPEがNHP_だけかRHPだけの1つへの都合のよいパケットサイズのどれかのためのセットであるなら、そのサイズは指定されたタイプのパケットのためだけに許容されています。
By default, no preferred packet sizes are specified. When sizes
are specified, the default value for RESTRICTED_TYPE is
NO_RESTRICTION.
デフォルトで、どんな都合のよいパケットサイズも指定されません。 サイズが指定されるとき、RESTRICTED_TYPEのためのデフォルト値はいいえ_RESTRICTIONです。
Jonsson, et. al Standards Track [Page 16] RFC 3242 A Link-Layer Assisted ROHC RTP April 2002
etイェンソン、アルStandards Track[16ページ]RFC3242A Link-層のAssisted ROHC RTP2002年4月
LARGE_PACKETS_ALLOWED -- value: boolean
LARGE_PACKETS_ALLOWED--値: 論理演算子
This parameter may be set by an external entity to specify how to
handle packets that do not fit any of the preferred packet sizes
specified. If it is set to TRUE, the compressor MUST deliver the
larger packet as-is and MUST NOT use segmentation. If it is set
to FALSE, the ROHC segmentation scheme MUST be used to split the
packet into two or more segments, and each segment MUST further be
padded to fit one of the preferred packet sizes.
外部実体によってこのパラメタがサイズが指定した都合のよいパケットのいずれにも合わないパケットを扱う方法を指定するように設定されるかもしれません。 それがTRUEに設定されるなら、コンプレッサーは、そのままでより大きいパケットを届けなければならなくて、分割を使用してはいけません。 それがFALSEに設定されるなら、パケットを2つ以上のセグメントに分けるのにROHC分割計画を使用しなければなりません、そして、都合のよいパケットサイズの1つに合うようにさらに各セグメントを水増ししなければなりません。
By default, this parameter is set to TRUE, which means that
segmentation is disabled.
デフォルトで、このパラメタはTRUEに設定されます。(TRUEは分割が障害があることを意味します)。
VERIFICATION_PERIOD -- value: integer
VERIFICATION_PERIOD--値: 整数
This parameter may be set by an external entity to specify to the
compressor the minimum frequency with which a packet validating
the context must be sent. This tells the compressor that a packet
containing a CRC field MUST be sent at least once every N packets,
where N=VERIFICATION_PERIOD (see section 4.6).
外部実体によってこのパラメタが文脈を有効にするパケットを送らなければならない最小の頻度をコンプレッサーに指定するように設定されるかもしれません。 これが、少なくとも一度CRC分野を含むパケットを送らなければならないとコンプレッサーに言う、あらゆる、Nパケット、どこN=VERIFICATION_PERIOD(セクション4.6を見ます)。
By default, this parameter is set to 0, which indicates that
periodical verifications are disabled.
デフォルトで、このパラメタは0へのセットです。(そのセットは定期刊行の検証は障害があるのを示します)。
5.1.2. Implementation Parameters at the Decompressor
5.1.2. 減圧装置における実現パラメタ
NHP_PACKET -- value: boolean
NHP_PACKET--値: 論理演算子
This parameter informs the decompressor that the packet being
delivered is an NHP packet. The decompressor MUST accept this
packet type indicator from the lower layer. An assisting layer
MUST set this indicator to true for every NHP packet delivered,
and to false for any other packet.
このパラメタは、届けられるパケットがNHPパケットであることを減圧装置に知らせます。 減圧装置は下層からこのパケットタイプインディケータを受け入れなければなりません。 補助層は届けられたあらゆるNHPパケットに本当と、そして、いかなる他のパケットにおいても誤ることにこのインディケータを設定しなければなりません。
PHYSICAL_PACKET_LOSS -- signal
PHYSICAL_PACKET_LOSS--合図してください。
This signal indicates to the decompressor that a packet has been
lost on the link between the compressing and the decompressing
sides, due to a physical link error. The signal is given once for
each packet that was lost, and a decompressor must increase the
sequence number accordingly when this signal is received.
この信号は、パケットが圧縮と減圧側とのリンクの上に失われたのを減圧装置に示します、物理的なリンク誤りのため。 失われた各パケットのために一度信号を与えます、そして、この信号が受信されているとき、減圧装置は一連番号をそれに従って、増加させなければなりません。
PRE_LINK_PACKET_LOSS -- signal
PRE_LINK_PACKET_LOSS--合図してください。
This signal tells the decompressor to increase the sequence number
due to a gap in the sequencing, not related to a physical link
error. A receiving assisting layer may for example use this
この信号は、物理的なリンク誤りに関連するのではなく、配列におけるギャップのため一連番号を増加させるように減圧装置に言います。 例えば、受信の補助層はこれを使用するかもしれません。
Jonsson, et. al Standards Track [Page 17] RFC 3242 A Link-Layer Assisted ROHC RTP April 2002
etイェンソン、アルStandards Track[17ページ]RFC3242A Link-層のAssisted ROHC RTP2002年4月
signal to indicate to the decompressor that a packet was lost
before the compressor, or that a packet was discarded by the
transmitting assisting layer.
層を補助しながら、パケットがコンプレッサーの前で失われたか、またはパケットが伝えることで捨てられたのを減圧装置に示すと合図してください。
5.2. Implementation over Various Link Technologies
5.2. 様々なリンク技術の上の実現
This document provides the semantics and requirements of the interface needed from the ROHC compressor and decompressor towards the assisting layer to perform link-layer assisted header compression.
このドキュメントはリンクレイヤの補助ヘッダー圧縮を実行するのに補助層に向かったROHCコンプレッサーと減圧装置から必要であるインタフェースの意味論と要件を提供します。
However, this document does not provide any link layer specific operational information, except for some implementation suggestions. Further details about how this profile is to be implemented over various link technologies must be described in other documents, where specific characteristics of each link layer can be taken into account to provide optimal usage of this profile.
しかしながら、このドキュメントはいくつかの実現提案以外の少しのリンクレイヤの特定の運用情報も提供しません。 他のドキュメントでこのプロフィールが様々なリンク技術の上でどう実行されることになっているかに関する詳細について説明しなければなりません。そこでは、このプロフィールの最適の使用法を提供するためにそれぞれのリンクレイヤの特定の特性を考慮に入れることができます。
These specifications MAY use a packet type bit pattern unused by this profile to implement signaling on the lower layer. The pattern available to lower layer implementations is [11111001].
下層で合図して、これらの仕様は実行するこのプロフィールによる未使用のパケットタイプビット・パターンを使用するかもしれません。 層の実現を下ろすために利用可能なパターンは[11111001]です。
6. IANA Considerations
6. IANA問題
ROHC profile identifier 0x0005 has been reserved by the IANA for the IP/UDP/RTP profile defined in this document.
ROHCプロフィール識別子0x0005は本書では定義されたIP/UDP/RTPプロフィールのためにIANAによって予約されました。
7. Security Considerations
7. セキュリティ問題
The security considerations of ROHC RTP [ROHC section 7] apply also to this document with one addition: in the case of a denial-of- service attack scenario where an intruder injects bogus CCP packets onto the link using random CRC values, the CRC check will fail for incorrect reasons at the decompressor side. This would obviously greatly reduce the advantages of ROHC and any extra efficiency provided by this profile due to unnecessary context invalidation, feedback messages and refresh packets. However, the same remarks related to the presence of such an intruder apply.
またROHC RTP[ROHC部7]の問題がこれに当てはまるセキュリティは1で添加を記録します: -不正確な理由で、侵入者が無作為のCRC値を使用することでにせのCCPパケットをリンクに注入するところでサービス攻撃シナリオでは、CRCチェックが減圧装置で失敗するという否定の場合では、面があってください。 これは、不要な文脈無効にするフィードバックメッセージのためROHCの利点とこのプロフィールによって提供されたどんな余分な効率も大いに明らかに減少させて、パケットをリフレッシュするでしょう。 しかしながら、そのような侵入者の存在に関連する同じ所見は適用されます。
8. Acknowledgements
8. 承認
The authors would like to thank Lila Madour, Ulises Olvera-Hernandez and Francis Lupien for input regarding the typical links in which LLA can be applied. Thanks also to Mikael Degermark for fruitful discussions that led to improvements of this profile, and to Zhigang Liu for many valuable comments.
作者はLLAを適用できる典型的なリンクに関する入力についてライラMadour、ウリセス・オルベラ-ヘルナンデス、およびフランシスLupienに感謝したがっています。 また、このプロフィールの改良につながった有意義な論議のためのマイケル・デーゲルマルクと、そして、多くの貴重なコメントのためのZhigangリュウをありがとうございます。
Jonsson, et. al Standards Track [Page 18] RFC 3242 A Link-Layer Assisted ROHC RTP April 2002
etイェンソン、アルStandards Track[18ページ]RFC3242A Link-層のAssisted ROHC RTP2002年4月
9. References
9. 参照
[ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima,
H., Hannu, H., Jonsson, L., 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.、Hakenberg、R.、コーレン、T.、Le、K.、リュウ、Z.、Martensson、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH.ツェン、「体力を要しているヘッダー圧縮(ROHC):」 枠組みと4個のプロフィール: 「RTP、超能力であって、解凍されたUDP」、RFC3095、7月2001日
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[IPv4] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[IPv6]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[UDP] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[RTP] Schulzrinne, H., Casner S., Frederick, R. and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 1889, January 1996.
[RTP] Schulzrinne、H.、Casner S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
[TCP] Postel, P., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[TCP] ポステル、P.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RTP-REQ] Degermark, M., "Requirements for IP/UDP/RTP Header
Compression", RFC 3096, July 2001.
[RTP-REQ] デーゲルマルク、M.、「IP/UDP/RTPヘッダー圧縮のための要件」、RFC3096、2001年7月。
[0B-REQ] Jonsson, L-E., "RObust Header Compression (ROHC):
Requirements and Assumptions for 0-byte IP/UDP/RTP
Compression", RFC 3243, April 2002.
[0B-REQ]イェンソン、L-E.、「体力を要しているヘッダー圧縮(ROHC):」 「0バイトのIP/UDP/RTP圧縮のための要件と仮定」、RFC3243、4月2002日
[VJHC] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990.
1990年2月の[VJHC]ジェーコブソン対「低速連続のリンクへのTCP/IPヘッダーを圧縮すること」でのRFC1144
[IPHC] Degermark, M., Nordgren, B. and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[IPHC] デーゲルマルクとM.とNordgrenとB.とS.ピンク、「IPヘッダー圧縮」、RFC2507、1999年2月。
[CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508, February
1999.
[CRTP]Casner、S.、およびRFC2508、1999年2月対「低速連続のリンクへのIP/UDP/RTPヘッダーを圧縮する」ジェーコブソン
[CRTPC] Degermark, M., Hannu, H., Jonsson, L-E. and K. Svanbro,
"Evaluation of CRTP Performance over Cellular Radio
Networks", IEEE Personal Communications Magazine, Volume
7, number 4, pp. 20-25, August 2000.
[CRTPC] デーゲルマルクとM.とハンヌとH.とイェンソンとL-E.とK.Svanbro、「セルラジオ放送網の上のCRTPパフォーマンスの評価」、IEEEパーソナルCommunications Magazine、Volume7、No.4、ページ 20-25と、2000年8月。
Jonsson, et. al Standards Track [Page 19] RFC 3242 A Link-Layer Assisted ROHC RTP April 2002
etイェンソン、アルStandards Track[19ページ]RFC3242A Link-層のAssisted ROHC RTP2002年4月
[VTC2000] Svanbro, K., Hannu, H., Jonsson, L-E. and M. Degermark,
"Wireless real time IP-services enabled by header
compression", proceedings of IEEE VTC2000, May 2000.
[VTC2000] SvanbroとK.とハンヌとH.とイェンソンとL-E.とM.デーゲルマルク、「ヘッダー圧縮で可能にされた無線のリアルタイムのIP-サービス」、IEEE VTC2000(2000年5月)の議事。
[MOMUC01] Liu, G., et al., "Experimental field trials results of
Voice-over IP over WCDMA links", MoMuC'01 - The
International Workshop on Mobile Multimedia
Communications, Conference proceedings, February 2001.
[MOMUC01] リュウ、G.、他、「WCDMAの上のボイス・オーバー IPの実験実地試験結果はリンクします」、MoMuC'01--モバイルMultimedia Communications、コンファレンス議事、2001年2月の国際Workshop。'
10. Authors' Addresses
10. 作者のアドレス
Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea Sweden
ラース-エリックイェンソンエリクソンAB箱920のSE-971 28ルーレオスウェーデン
Phone: +46 920 20 21 07 Fax: +46 920 20 20 99 EMail: lars-erik.jonsson@ericsson.com
以下に電話をしてください。 +46 920 20 21 07、Fax: +46 920 20 20 99はメールされます: lars-erik.jonsson@ericsson.com
Ghyslain Pelletier Ericsson AB Box 920 SE-971 28 Lulea Sweden
GhyslainペレティアエリクソンAB箱920のSE-971 28ルーレオスウェーデン
Phone: +46 920 20 24 32 Fax: +46 920 20 20 99 EMail: ghyslain.pelletier@epl.ericsson.se
以下に電話をしてください。 +46 920 20 24 32、Fax: +46 920 20 20 99はメールされます: ghyslain.pelletier@epl.ericsson.se
Jonsson, et. al Standards Track [Page 20] RFC 3242 A Link-Layer Assisted ROHC RTP April 2002
etイェンソン、アルStandards Track[20ページ]RFC3242A Link-層のAssisted ROHC RTP2002年4月
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Jonsson, et. al Standards Track [Page 21]
etイェンソン、アルStandards Track[21ページ]
一覧
スポンサーリンク
