RFC4362 日本語訳
4362 RObust Header Compression (ROHC): A Link-Layer Assisted Profilefor IP/UDP/RTP. L-E. Jonsson, G. Pelletier, K. Sandlund. January 2006. (Format: TXT=53926 bytes) (Obsoletes RFC3242) (Updated by RFC4815) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group L-E. Jonsson
Request for Comments: 4362 G. Pelletier
Obsoletes: 3242 K. Sandlund
Category: Standards Track Ericsson
January 2006
ワーキンググループL-Eをネットワークでつないでください。 コメントを求めるイェンソンRequest: 4362 G.ペレティアは以下を時代遅れにします。 3242年のK.Sandlundカテゴリ: 標準化過程エリクソン2006年1月
RObust Header Compression (ROHC):
A Link-Layer Assisted Profile for IP/UDP/RTP
体力を要しているヘッダー圧縮(ROHC): リンクレイヤはIP/UDP/RTPのためにプロフィールを補助しました。
Status of This 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 (2006).
Copyright(C)インターネット協会(2006)。
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 related to the usage of the header-free packet format. This document is a replacement for RFC 3242, which it obsoletes.
このドキュメントはIP/UDP/RTP(インターネットのリアルプロトコル/ユーザー・データグラム・プロトコル/タイムのTransportプロトコル)パケットの圧縮のためのROHC(強健なHeader Compression)プロフィールを定義します、下層によって提供された、ほとんどのパケットのために最適の操作の間、ヘッダーを完全に排除することによって圧縮効率を増加させた機能性を利用して。 プロフィールは拡大としてROHC RTPプロフィールに造られます。 それは、ROHCで必要である追加メカニズムを定義して、透明を保証するという補助層に関する要件を述べて、無ヘッダーのパケット・フォーマットの用法に関連する圧縮と減圧に一般的な論理を指定します。 このドキュメントはRFC3242への交換品です。(それはRFCを時代遅れにします)。
Jonsson, et al. Standards Track [Page 1] RFC 4362 A Link-Layer Assisted ROHC RTP January 2006
イェンソン、他 リンクレイヤがROHC RTP2006年1月に補助した標準化過程[1ページ]RFC4362
Table of Contents
目次
1. Introduction ....................................................2
1.1. Differences from RFC 3242 ..................................5
2. Terminology .....................................................5
3. Overview of the Link-Layer Assisted Profile .....................6
3.1. Providing Packet Type Identification .......................7
3.2. Replacing the Sequence Number ..............................7
3.3. CRC Replacement ............................................8
3.4. Applicability of This Profile ..............................8
4. Additions and Exceptions Compared to ROHC RTP ...................9
4.1. Additional Packet Types ....................................9
4.1.1. No-Header Packet (NHP) ..............................9
4.1.2. Context Synchronization Packet (CSP) ................9
4.1.3. Context Check Packet (CCP) .........................11
4.2. Interfaces Towards the Assisting Layer ....................12
4.2.1. Interface, Compressor to Assisting Layer ...........13
4.2.2. Interface, Assisting Layer to Decompressor .........13
4.3. Optimistic Approach Agreement .............................14
4.4. Fast Context Initialization, IR Redefinition ..............15
4.5. Feedback Option, CV-REQUEST ...............................16
4.6. Periodic Context Verification .............................16
4.7. Use of Context Identifier .................................16
5. Implementation Issues ..........................................17
5.1. Implementation Parameters and Signals .....................17
5.1.1. Implementation Parameters at the Compressor ........17
5.1.2. Implementation Parameters at the Decompressor ......19
5.2. Implementation over Various Link Technologies .............19
6. IANA Considerations ............................................20
7. Security Considerations ........................................20
8. Acknowledgements ...............................................20
9. References .....................................................20
9.1. Normative References ......................................20
9.2. Informative References ....................................21
1. 序論…2 1.1. RFC3242からの違い…5 2. 用語…5 3. リンクレイヤの概観はプロフィールを補助しました…6 3.1. パケットを提供して、識別をタイプしてください…7 3.2. 一連番号を置き換えます…7 3.3. CRC交換…8 3.4. このプロフィールの適用性…8 4. 追加と例外はROHC RTPと比較されました…9 4.1. 追加パケットはタイプされます…9 4.1.1. ヘッダーがないパケット(NHP)…9 4.1.2. 文脈同期パケット(CSP)…9 4.1.3. 文脈チェックパケット(CCP)…11 4.2. 補助に向かったインタフェースは層にされます…12 4.2.1. インタフェース、補助へのコンプレッサーは層にされます…13 4.2.2. 減圧装置に層を補助して、連結してください…13 4.3. 楽観的なアプローチ協定…14 4.4. 速い文脈初期設定、IR Redefinition…15 4.5. フィードバックオプション、CV-要求…16 4.6. 周期的な文脈検証…16 4.7. 文脈識別子の使用…16 5. 実現問題…17 5.1. 実現パラメタと信号…17 5.1.1. コンプレッサーの実現パラメタ…17 5.1.2. 減圧装置における実現パラメタ…19 5.2. 様々なリンク技術の上の実現…19 6. IANA問題…20 7. セキュリティ問題…20 8. 承認…20 9. 参照…20 9.1. 標準の参照…20 9.2. 有益な参照…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
ヘッダー圧縮は1ホップあたり1個のベースのパケットに関するヘッダー情報を圧縮して、透明に減圧するのに使用されるテクニックです、パケットの流れの中で個々のパケットと連続したパケットの間の冗長を利用して。 数年間、いくつかのプロトコル[VJHC、IPHC]がネットワークとトランスポート・プロトコルヘッダー[IPv4、IPv6、UDP、TCP]を圧縮するために開発されています、そして、これらの計画は多くのワイヤードなボトルネックリンクの上に能率を増進するのに成功しています、電話網の上のモデム接続などのように。 IP、UDP、およびTCP圧縮に加えて、Compressed RTP[CRTP]と呼ばれる追加圧縮技術に開発されました。
Jonsson, et al. Standards Track [Page 2] RFC 4362 A Link-Layer Assisted ROHC RTP January 2006
イェンソン、他 リンクレイヤがROHC RTP2006年1月に補助した標準化過程[2ページ]RFC4362
improve compression efficiency further for real-time traffic using the Real-Time Transport Protocol [RTP].
レアル-時間Transportプロトコル[RTP]を使用することでさらにリアルタイムの交通に圧縮効率を高めてください。
The schemes mentioned above have all been designed by 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 header compression performance [CRTPC]. This problem was the driving force behind the creation of the RObust Header Compression (ROHC) WG in the IETF.
前記のように計画は、ワイヤードなリンクだけに伝統的に基づいたリンクの特性に関する通常の仮定を考慮に入れることによって、すべて設計されています。 しかしながら、一般に、増加する数の無線のリンクがインターネット経路にある状態で、これらの仮定はもう有効ではありません。 無線の環境、特に広い適用範囲のセル環境で、比較的高い誤り率は、ラジオリソースの効率的な用法を許容するために許容されます。 そのような運転条件は例えば、3番目の世代のセルリンクの上にリアルタイムの交通への、標準になるでしょう、そして、したがって、ヘッダー圧縮はパケット損失を黙認しなければなりません。(交通は誤りより遅れに敏感です)。 しかしながら、以前に言及された計画で、特にCRTPによって圧縮されたリアルタイムの交通において、高い誤り率は、ヘッダー圧縮性能[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 when 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 also been designed to 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
以上のように、3番目の世代セルラ方式はIPが終わりから中古の終わりになるところのROHC RTPの後ろの原動力の1つです、そして、また、計画は新しいセル空気インタフェースに合うように設計されています、WCDMAなどのように、スペクトル効率が1サービスのサーキットが存在するように、解決策[VTC2000]を切り換えたより無意味に低い状態でスピーチサービスさえ走らせるのを可能にして。 そして、しかしながら、他の空気が連結する、(GSMに基づくものなど、-95である、)、また、オールIPネットワークに使用されるでしょう、ヘッダー圧縮問題のためのさらなる含意で。 ラジオ運搬人が特定のペイロードサイズのために最適化されている状態で、これらのより古い空気インタフェースはそれほどフレキシブルではありません。 これは、使用なしでヘッダーの1つの八重奏もさえ加えることができないことを意味します。
Jonsson, et al. Standards Track [Page 3] RFC 4362 A Link-Layer Assisted ROHC RTP January 2006
イェンソン、他 リンクレイヤがROHC RTP2006年1月に補助した標準化過程[3ページ]RFC4362
next higher fixed packet size supported by the link, something that 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 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.
リンクによって支持された次の、より高い固定パケットサイズ、明らかに非常に何か高価なもの。 その結果、既存のサーキットで切り換えられた解決策と比べて、これらのリンクの上のスペクトル効率は既に配備されたスピーチボコーダに関しては低くなるでしょう。 どんなアプリケーションでも全体的に見て高いスペクトル効率を達成するために、よりフレキシブルな空気インタフェースを配備しなければなりません、そして、次に、ROHC RTP計画はすばらしく働くでしょう、WCDMA[MOMUC01]のために示されるように。 しかしながら、展開理由で、また、既に存在するための適当なヘッダー圧縮戦略にボコーダを提供して、GERANやCDMA2000などのインタフェースを空気に提供するのは重要です、スペクトル効率への最小量の効果で。
This document describes a link-layer-assisted ROHC RTP profile, originally defined by [LLA], extending ROHC RTP (profile 0x0001) [ROHC], and compliant with the ROHC 0-byte requirements [0B-REQ]. The purpose of this profile is to provide a header-free packet format that, for a certain application 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.
このドキュメントはROHCの0バイトの要件[0B-REQ]で[ROHC]の、そして、言いなりになっているROHC RTP(プロフィール0x0001)を広げる元々[LLA]によって定義されたリンク層が補助された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と下層によって一緒に提供されるのを保証するために注意しなければなりません。 したがって、追加ドキュメントは様々なリンク技術の上にこのプロフィールを組み込む方法を指定するはずです。
The profile defined by this document was originally specified by RFC 3242 [LLA], but to address one technical flaw and clarify one implementation issue, this document has been issued to replace RFC 3242, which becomes obsolete.
RFC3242[LLA]は元々、このドキュメントによって定義されたプロフィールを指定しましたが、1つの技術的な欠点を記述して、1つの導入問題をはっきりさせるなら、RFC3242を取り替えるためにこのドキュメントを発行しました。(RFCは時代遅れになります)。
Jonsson, et al. Standards Track [Page 4] RFC 4362 A Link-Layer Assisted ROHC RTP January 2006
イェンソン、他 リンクレイヤがROHC RTP2006年1月に補助した標準化過程[4ページ]RFC4362
1.1. Differences from RFC 3242
1.1. RFC3242からの違い
This section briefly summarizes the differences of this document from RFC 3242. Acronyms and terminology can be found in Section 2.
このセクションはRFC3242からこのドキュメントの違いを簡潔にまとめます。 セクション2で頭文字語と用語を見つけることができます。
The format of the CSP packet, as defined in [LLA], was identified as non-interoperable when carrying a RHP header with a 3-bit or 7-bit CRC. This problem occurs because the payload has been dropped by the compressor, and the decompressor is supposed to use the payload length to infer certain fields in the uncompressed header. These fields are the IPv4 total length, the IPv6 payload length, the UDP length, and the IPv4 header checksum field (all INFERRED fields in [ROHC]). To correct this flaw, the CSP packet must carry information about the payload length of the RHP packet. Therefore, the length of the RTP payload has been included in the CSP packet.
3ビットの、または、7ビットのCRCと共にRHPヘッダーを運ぶとき、[LLA]で定義されるCSPパケットの書式は非共同利用できるとして特定されました。 ペイロードがコンプレッサーによって落とされたので、この問題は起こります、そして、減圧装置は解凍されたヘッダーのある一定の分野を推論するのにペイロード長を使用するべきです。 これらの分野は全長、IPv6ペイロード長、UDPの長さ、およびIPv4ヘッダーチェックサムがさばくIPv4([ROHC]のすべてのINFERRED分野)です。 この欠点を修正するために、CSPパケットはRHPパケットのペイロード長の情報を運ばなければなりません。 したがって、RTPペイロードの長さはCSPパケットに含まれています。
This document also clarifies an unclear referencing in RFC 3242, where Section 4.1.3 of [LLA] states that upon CRC failure, the actions of [ROHC], Section 5.3.2.2.3 MUST be taken. That section specifies that detection of SN wraparound and local repair must be performed, but neither of these steps apply when the failing packet is a CCP. Therefore, upon CRC failure, actions to be taken are the ones specified in Section 5.3.2.2.3, but steps a-d only.
そこでは、.3セクション4.1[LLA]がCRCの故障にそれを述べます。また、このドキュメントはRFC3242で不明瞭な参照箇所をはっきりさせます、[ROHC]の動作、セクション5.3。.2 .2 .3 取らなければなりません。 そのセクションは、SN巻きつけて着るドレスと局部的修繕の検出を実行しなければならないと指定しますが、失敗パケットがCCPであるときに、これらのステップのどちらも適用されません。 取られるべき動作はしたがって、CRCの故障では、セクション5.3で指定されたものです。.2 .2 .3 しかし、ステップa-d専用。
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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 5] RFC 4362 A Link-Layer Assisted ROHC RTP January 2006
イェンソン、他 リンクレイヤがROHC RTP2006年1月に補助した標準化過程[5ページ]RFC4362
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" refers to the IP/UDP/RTP profile as defined in [ROHC].
"ROHC RTP"は[ROHC]で定義されるIP/UDP/RTPプロフィールを示します。
3. Overview of the Link-Layer Assisted Profile
3. リンクレイヤの補助プロフィールの概観
The ROHC IP/UDP/RTP profile defined in [LLA] and updated by this document, profile 0x0005 (hex), is designed to be used over channels that have been optimized for specific payload sizes and that therefore cannot efficiently accommodate header information when transmitted together with payloads corresponding to these optimal sizes.
これらの最適規模に対応するペイロードと共に伝えられると、[LLA]で定義されて、このドキュメントによってアップデートされた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, this profile replaces 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 6] RFC 4362 A Link-Layer Assisted ROHC RTP January 2006
イェンソン、他 リンクレイヤがROHC RTP2006年1月に補助した標準化過程[6ページ]RFC4362
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. It will be possible to distinguish ROHC RTP packets with compressed headers 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, the compressing side, if needed, 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 that which the VJ header compression [VJHC] relies on.
しかしながら、トランスミッションポイントでは、リンクの上に発生するかもしれない損失か再命令は、予期して、守ることができません。 したがって、NHPに関して、補助層は、リンク([ROHC]によって既に想定される)の上と、そして、受信側では、リンクの上の各パケット損失のための指示を提供しなければならないのをオーダーにおける配送に保証しなければなりません。 これは基本的にVJヘッダー圧縮[VJHC]が当てにするそれと同じ原則です。
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 link losses and bit errors in the compressed sequence number.
圧縮された一連番号におけるリンクの損失と噛み付いている誤りのためリンクの上のオーダーにおける配送とパケット損失指示を保証すると通常、誤りの世話をするCRCの主な機能が一連番号情報を推論するのを可能にするだけではなく、取って代わられもすることに注意してください。
Jonsson, et al. Standards Track [Page 7] RFC 4362 A Link-Layer Assisted ROHC RTP January 2006
イェンソン、他 リンクレイヤがROHC RTP2006年1月に補助した標準化過程[7ページ]RFC4362
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.
1) 一連番号LSBsで覆うことができるより長い損失の検出。
2) Protection against failures caused by residual bit errors in
compressed headers.
2) 残差によって引き起こされた失敗に対する保護は圧縮されたヘッダーで誤りに噛み付きました。
3) Protection against faulty implementations and other causes of
error.
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 an 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. Thus, whether LLA or ROHC RTP should be implemented depends on the characteristics of the link itself. For most RTP packet streams, LLA will work exactly as ROHC RTP, and it will have a higher compression efficiency for packet streams with certain characteristics. LLA will never have a lower compression efficiency 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 8] RFC 4362 A Link-Layer Assisted ROHC RTP January 2006
イェンソン、他 リンクレイヤがROHC RTP2006年1月に補助した標準化過程[8ページ]RFC4362
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) is a packet that consists only of the payload of the original packet. The NHP MAY be used when only the sequence information needs to be conveyed to the decompressor. In other words, the NHP can be used 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 sections 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 MAY、系列情報だけが、減圧装置まで運ばれる必要があるときには、使用されてください。 言い換えれば、すべてのヘッダーフィールドが変わりがないか、または現在確立した変化パターンに従うとき、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
a)で、パケットのための適切な配列を推論する手段はX-1、SN=ANDに対応するようになります。
b) has either received a loss indication or the packet itself for
the packet corresponding to 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 discarded data, which may result in decompressor context invalidation. It might therefore be beneficial to send a packet with only the header information and to 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 9] RFC 4362 A Link-Layer Assisted ROHC RTP January 2006
イェンソン、他 リンクレイヤがROHC RTP2006年1月に補助した標準化過程[9ページ]RFC4362
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
+===+===+===+===+===+===+===+===+
/ RTP Payload Length / 2 octets
+---+---+---+---+---+---+---+---+
: 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 | パケットタイプ識別子+===+===+===+===+===+===+===+===+/RTP有効搭載量Length / 2八重奏+---+---+---+---+---+---+---+---+ : 詰め物のないROHCヘッダー: : [ROHC、セクション5.7]は見ます: +---+---+---+---+---+---+---+---+
RTP Payload Length: This field is the length of the payload carried
inside the RTP header, stored in network byte
order. That is, this field will be set by the
compressor to (UDP length - size of the UDP
header - size of the RTP header including CSRC
identifiers).
RTPペイロード長: この分野はネットワークバイトオーダーに格納されたRTPヘッダーの中に運ばれたペイロードの長さです。 すなわち、この分野は(UDPの長さ--UDPヘッダーのサイズ--CSRC識別子を含むRTPヘッダーのサイズ)へのコンプレッサーによって設定されるでしょう。
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に適用されるかもしれません。
In the CSP packet, the payload has been dropped by the compressor. However, the decompressor is supposed to use the payload length to infer certain fields in the uncompressed header (the IPv4 total length, the IPv6 payload length, the UDP length, and the IPv4 header checksum field). When dropping the payload, the CSP packet needs to contain information about the payload length carried in the RHP packet. Therefore, the length of the RTP payload is carried in the CSP packet. When the decompressor receives a CSP packet, it can use the RTP payload length field to calculate the value of fields classified as INFERRED in [ROHC] when attempting to verify a 3- or 7-bit CRC carried in the RHP header enclosed in the CSP.
CSPパケットでは、ペイロードはコンプレッサーによって落とされました。 しかしながら、減圧装置は、解凍されたヘッダー(全長、IPv6ペイロード長、UDPの長さ、およびIPv4ヘッダーチェックサムがさばくIPv4)のある一定の分野を推論するのにペイロード長を使用するべきです。 ペイロードを落とすとき、CSPパケットは、RHPパケットで運ばれたペイロード長の情報を含む必要があります。 したがって、RTPペイロードの長さはCSPパケットで運ばれます。 減圧装置がCSPパケットを受けるとき、それは、3か7ビットのCRCについて確かめるのを試みるとき、[ROHC]のINFERREDがCSPに同封されたRHPヘッダーで運んだので分類された分野の値について計算するのにRTPペイロード長分野を使用できます。
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に続いて、どんな可能なデータも含んでいると、圧縮されたヘッダーはカプセルに入れられた)を捨てなければならないことに注意してください。
Jonsson, et al. Standards Track [Page 10] RFC 4362 A Link-Layer Assisted ROHC RTP January 2006
イェンソン、他 リンクレイヤがROHC RTP2006年1月に補助した標準化過程[10ページ]RFC4362
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には、以下の形式があります:
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. If C=1, the CRC field MUST be set to the 7-bit 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=1)Cビットで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 to 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
減圧装置は有効なCRC分野を示して、設定された(C=1)Cビットで受け取られたCCPを扱って、文脈検証を実行するREQUIREDです。 aパケット損失指示が以前に最後に減圧されたパケット受けられなかったなら適用されていて、その時、CRC MUSTを受けました。 CRCの故障では、指定されて、動作として取らなければなりません。
Jonsson, et al. Standards Track [Page 11] RFC 4362 A Link-Layer Assisted ROHC RTP January 2006
イェンソン、他 リンクレイヤがROHC RTP2006年1月に補助した標準化過程[11ページ]RFC4362
[ROHC, Section 5.3.2.2.3, steps a-d only]. 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.
[ROHC、セクション5.3.2、.2、.3、ステップa-d専用] 減圧装置でC=0で受け取られたCCPを無視しなければなりません。 減圧装置はCCPの少しのさらなる解釈もすることができません。
When using the 7-bit CRC in the CCP packet to verify the context, the decompressor needs to have access to the entire uncompressed header of the latest packet decompressed. Some implementations of [ROHC] might not save the values of INFERRED fields. An implementation of ROHC LLA MUST save these fields in the decompressor context to be able to successfully verify CCP packets.
文脈、減圧装置について確かめるCCPパケットのCRCが近づく手段を持つ必要がある7ビットを使用するとき、最新のパケットの全体の解凍されたヘッダーは減圧しました。 [ROHC]のいくつかの実現はINFERRED分野の値を節約しないかもしれません。 ROHC LLA MUSTの実現は、首尾よくCCPパケットについて確かめることができるように減圧装置文脈のこれらの分野を節約します。
The use of CCP by an assisting layer is optional and depends on the characteristics of the actual link. Whether it is used MUST therefore be specified in link-layer implementation specifications for this profile.
補助層のそばのCCPの使用は、任意であり、実際のリンクの特性に依存します。 したがって、このプロフィールのためのリンクレイヤ実現仕様でそれが使用されているかどうか指定しなければなりません。
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
このセクションは、このプロフィールが操作するLLAコンプレッサーと補助層の間で交換するために情報を定義します。
Jonsson, et al. Standards Track [Page 12] RFC 4362 A Link-Layer Assisted ROHC RTP January 2006
イェンソン、他 リンクレイヤがROHC RTP2006年1月に補助した標準化過程[12ページ]RFC4362
properly. While it does define semantics, it does not specify how these interfaces are to be implemented.
適切に。 意味論を定義しますが、それはこれらのインタフェースが実行されることになっている方法を指定しません。
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を届けます。
This corresponds to the case when the compressor allows sending
of an NHP packet, with or without segmentation 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
ここで、補助層と減圧装置の間のインタフェース意味論は定義されます、容認されたパケットの配送のための簡単な規則を減圧装置に提供して。 減圧装置は道を必要とします。
Jonsson, et al. Standards Track [Page 13] RFC 4362 A Link-Layer Assisted ROHC RTP January 2006
イェンソン、他 リンクレイヤがROHC RTP2006年1月に補助した標準化過程[13ページ]RFC4362
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.
- 圧縮と減圧とのリンクの上の各パケット損失のための指示にCID=0であるときに面があります。
- the received packet together with an indication of whether the
packet received is an NHP.
- パケットが受信されたかどうかしるしに伴う容認されたパケットはNHPです。
Note that the context is updated from a packet loss indication.
パケット損失指示から文脈をアップデートすることに注意してください。
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 if three or more consecutive physical packets are lost. 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 to between the compressing side and the decompressing side. It could be handled with a fixed principle, with
LLAプロフィールが、あるリンク技術の上でどう実行されるかを説明するすべてのドキュメントが楽観的なアプローチが圧縮側と減圧側の間でどう同意されるかを定義するのは、REQUIREDです。 固定原則でそれを扱うことができました。
Jonsson, et al. Standards Track [Page 14] RFC 4362 A Link-Layer Assisted ROHC RTP January 2006
イェンソン、他 リンクレイヤがROHC RTP2006年1月に補助した標準化過程[14ページ]RFC4362
negotiation at startup, or by other means, but the method must be unambiguously defined.
明白に始動における、または、他の手段による交渉、しかし、方法を定義しなければなりません。
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 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.
ROHC RTP IRパケットの基本構造からのこの目的、D-ビットに役立つ、[ROHC、セクション5.7 .7 .1は]LLAプロフィールのために再定義されます。 D=0(ダイナミックなチェーンがない)に関しては、D-ビットの意味は、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 that 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パケットが減圧装置によって処理された後に、パケットを捨てなければなりません。
Jonsson, et al. Standards Track [Page 15] RFC 4362 A Link-Layer Assisted ROHC RTP January 2006
イェンソン、他 リンクレイヤがROHC RTP2006年1月に補助した標準化過程[15ページ]RFC4362
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 NHPs have been received for a long time and the context therefore has not been verified recently.
CV-REQUESTオプションは減圧装置によって使用されて、文脈検証のためにRRPかCSPを要求するかもしれません。 長い間NHPsだけを受け取っていて、したがって、最近文脈について確かめていないなら、このオプションを使用するべきです。
+---+---+---+---+---+---+---+---+ | 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として補助層に渡してください。
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 that context updating packets be sent periodically, 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とのパケットの流れ)があるパケットが失われたかどうか言うことができなければならないかを言うことができなければならないことに注意してください。
Jonsson, et al. Standards Track [Page 16] RFC 4362 A Link-Layer Assisted ROHC RTP January 2006
イェンソン、他 リンクレイヤがROHC RTP2006年1月に補助した標準化過程[16ページ]RFC4362
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 section 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パラメタを時代遅れにすることに注意してください。
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 ROHC padding
of one octet, minimum.
外部実体によってこのパラメタが、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
このパラメタセットは、どのパケットサイズが補助層によって好まれるかを治めます。 このパラメタセットが使用されているなら、可能な限りわずかな優先サイズに合うようにすべてのRHPパケットを水増ししなければなりません。 または、非水増しパケットのサイズである、(ALWAYS_PADに関するケース
Jonsson, et al. Standards Track [Page 17] RFC 4362 A Link-Layer Assisted ROHC RTP January 2006
イェンソン、他 リンクレイヤがROHC RTP2006年1月に補助した標準化過程[17ページ]RFC4362
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.
セット、最小量の1八重奏の詰め物があるパケットです) 最大限度の都合のよいパケットサイズ、コンプレッサーがそうしたより大きい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です。
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へのセットです。(そのセットは定期刊行の検証は障害があるのを示します)。
Jonsson, et al. Standards Track [Page 18] RFC 4362 A Link-Layer Assisted ROHC RTP January 2006
イェンソン、他 リンクレイヤがROHC RTP2006年1月に補助した標準化過程[18ページ]RFC4362
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
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]です。
Jonsson, et al. Standards Track [Page 19] RFC 4362 A Link-Layer Assisted ROHC RTP January 2006
イェンソン、他 リンクレイヤがROHC RTP2006年1月に補助した標準化過程[19ページ]RFC4362
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 using random CRC values onto the link, 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リュウをありがとうございます。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[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日
[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", STD 64, RFC 3550, July 2003.
[RTP] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
Jonsson, et al. Standards Track [Page 20] RFC 4362 A Link-Layer Assisted ROHC RTP January 2006
イェンソン、他 リンクレイヤがROHC RTP2006年1月に補助した標準化過程[20ページ]RFC4362
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
9.2. Informative References
9.2. 有益な参照
[LLA] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
(ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC
3242, April 2002.
[LLA]イェンソン、L-E.、およびG.ペレティア、「体力を要しているヘッダー圧縮(ROHC):」 「リンクレイヤはIP/UDP/RTPのためにプロフィールを補助した」RFC3242、2002年4月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[TCP] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RTP-REQ] Degermark, M., "Requirements for robust 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.
[VJHC] ジェーコブソン、V.、「低速連続のリンクへのTCP/IPヘッダーを圧縮します」、RFC1144、1990年2月。
[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月。
[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。'
Jonsson, et al. Standards Track [Page 21] RFC 4362 A Link-Layer Assisted ROHC RTP January 2006
イェンソン、他 リンクレイヤがROHC RTP2006年1月に補助した標準化過程[21ページ]RFC4362
Authors' Addresses
作者のアドレス
Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea, Sweden
ラース-エリックイェンソンエリクソンAB箱920のSE-971 28ルーレオ(スウェーデン)
Phone: +46 8 404 29 61 Fax: +46 920 996 21 EMail: lars-erik.jonsson@ericsson.com
以下に電話をしてください。 +46 8 404、29 61、Fax: +46 920 996 21メール: lars-erik.jonsson@ericsson.com
Ghyslain Pelletier Ericsson AB Box 920 SE-971 28 Lulea, Sweden
GhyslainペレティアエリクソンAB箱920のSE-971 28ルーレオ(スウェーデン)
Phone: +46 8 404 29 43 Fax: +46 920 996 21 EMail: ghyslain.pelletier@ericsson.com
以下に電話をしてください。 +46 8 404、29 43、Fax: +46 920 996 21メール: ghyslain.pelletier@ericsson.com
Kristofer Sandlund Ericsson AB Box 920 SE-971 28 Lulea, Sweden
クリストファSandlundエリクソンAB箱920のSE-971 28ルーレオ(スウェーデン)
Phone: +46 8 404 41 58 Fax: +46 920 996 21 EMail: kristofer.sandlund@ericsson.com
以下に電話をしてください。 +46 8 404、41 58、Fax: +46 920 996 21メール: kristofer.sandlund@ericsson.com
Jonsson, et al. Standards Track [Page 22] RFC 4362 A Link-Layer Assisted ROHC RTP January 2006
イェンソン、他 リンクレイヤがROHC RTP2006年1月に補助した標準化過程[22ページ]RFC4362
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Jonsson, et al. Standards Track [Page 23]
イェンソン、他 標準化過程[23ページ]
一覧
スポンサーリンク
