RFC4815 日本語訳
4815 RObust Header Compression (ROHC): Corrections and Clarificationsto RFC 3095. L-E. Jonsson, K. Sandlund, G. Pelletier, P. Kremer. February 2007. (Format: TXT=74819 bytes) (Updates RFC3095, RFC3241, RFC3843, RFC4019, RFC4362) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group L-E. Jonsson
Request for Comments: 4815 K. Sandlund
Updates: 3095, 3241, 3843, 4019, 4362 G. Pelletier
Category: Standards Track P. Kremer
February 2007
ワーキンググループL-Eをネットワークでつないでください。 コメントを求めるイェンソンRequest: 4815のK.Sandlundアップデート: 3095、3241、3843、4019、4362G.ペレティアカテゴリ: 標準化過程P.クレーメル2007年2月
RObust Header Compression (ROHC):
Corrections and Clarifications to RFC 3095
体力を要しているヘッダー圧縮(ROHC): RFC3095への修正と明確化
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 IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles for IP (Internet Protocol), UDP (User Datagram Protocol), RTP (Real-Time Transport Protocol), and ESP (Encapsulating Security Payload). Some parts of the specification are unclear or contain errors that may lead to misinterpretations that may impair interoperability between different implementations. This document provides corrections, additions, and clarifications to RFC 3095; this document thus updates RFC 3095. In addition, other clarifications related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) and RFC 4109 (ROHC UDP-Lite profiles) are also provided.
RFC3095はIP(インターネットプロトコル)、UDP(ユーザー・データグラム・プロトコル)、RTP(リアルタイムのTransportプロトコル)、および超能力のためのRObust Header Compression(ROHC)枠組みとプロフィールを定義します(Security有効搭載量を要約して)。 仕様のいくつかの部分が、不明瞭であるか、または異なった実現の間に相互運用性を損なうかもしれない誤解につながるかもしれない誤りを含んでいます。 このドキュメントは修正、追加、および明確化をRFC3095に供給します。 その結果、このドキュメントはRFC3095をアップデートします。 さらに、他の明確化はRFC3241(PPPの上のROHC)に関連しました、また、RFC3843(ROHC IPプロフィール)とRFC4109(ROHC UDP-Liteプロフィール)を提供します。
Jonsson, et al. Standards Track [Page 1] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
イェンソン、他 規格は2007年2月にRFC4815修正と明確化をRFC3095に追跡します[1ページ]。
Table of Contents
目次
1. Introduction and Terminology ....................................3
2. CRC Calculation and Coverage ....................................4
2.1. CRC Calculation ............................................4
2.2. Padding Octet and CRC Calculations .........................4
2.3. CRC Coverage in CRC Feedback Options .......................5
2.4. CRC Coverage of the ESP NULL Header ........................5
3. Mode Transition .................................................5
3.1. Feedback During Mode Transition to U- and O-Mode ...........5
3.1.1. Mode Transition Procedures Allowing Sparse Feedback .6
3.1.2. Transition from Reliable to Optimistic Mode .........7
3.1.3. Transition to Unidirectional Mode ...................8
3.2. Feedback During Mode Transition ............................8
3.3. Packet Decoding During Mode Transition .....................9
4. Timestamp Encoding ..............................................9
4.1. Encoding Used for Compressed TS Bits .......................9
4.2. (De)compression of TS without Transmitted TS Bits .........10
4.3. Interpretation Intervals for TS Encoding ..................11
4.4. Scaled RTP Timestamp Encoding .............................11
4.4.1. TS_STRIDE for Scaled Timestamp Encoding ............11
4.4.2. TS Wraparound with Scaled Timestamp Encoding .......12
4.4.3. Algorithm for Scaled Timestamp Encoding ............12
4.5. Recalculating TS_OFFSET ...................................14
4.6. TS_STRIDE and the Tsc Flag in Extension 3 .................14
4.7. Using Timer-Based Compression .............................15
5. List Compression ...............................................15
5.1. CSRC List Items in RTP Dynamic Chain ......................15
5.2. Multiple Occurrences of the CC Field ......................15
5.3. Bit Masks in List Compression .............................16
5.4. Headers Compressed with List Compression ..................16
5.5. ESP NULL Header List Compression ..........................17
5.6. Translation Tables and Indexes for IP Extension Headers ...17
5.7. Reference List ............................................17
5.8. Compression of AH and GRE Sequence Numbers ................18
6. Updating Properties ............................................19
6.1. Implicit Updates ..........................................19
6.2. Updating Properties of UO-1* ..............................20
6.3. Context Updating Properties for IR Packets ................20
6.4. RTP Padding Field (R-P) in Extension 3 ....................20
6.5. RTP eXtension bit (X) in dynamic part .....................21
7. Context management and CID/context Reuse .......................21
7.1. Persistence of Decompressor Contexts ......................21
7.2. CID/Context Reuse .........................................21
7.2.1. Reusing a CID/Context with the Same Profile ........22
7.2.2. Reusing a CID/Context with a Different Profile .....23
8. Other Protocol Clarifications ..................................23
8.1. Meaning of NBO ............................................23
1. 序論と用語…3 2. CRC計算と適用範囲…4 2.1. CRC計算…4 2.2. 八重奏とCRC計算を水増しします…4 2.3. CRCフィードバックオプションにおけるCRC適用範囲…5 2.4. 超能力ヌルヘッダーのCRC適用範囲…5 3. モード変遷…5 3.1. Uへのモード変遷の間のフィードバックとO-モード…5 3.1.1. モード変遷手順許容まばらなフィードバック.6 3.1.2。 信頼できるモードから楽観的なモードまでの変遷…7 3.1.3. 単方向のモードへの変遷…8 3.2. モード変遷の間のフィードバック…8 3.3. モード変遷の間に解読するパケット…9 4. タイムスタンプコード化…9 4.1. コード化は圧縮されたtにビットを使用しました…9 4.2. (De)Transmitted TS BitsのないTSの圧縮…10 4.3. tコード化のための解釈間隔…11 4.4. RTPタイムスタンプコード化をスケーリングします…11 4.4.1. t_はスケーリングされたタイムスタンプコード化のために大股で歩きます…11 4.4.2. スケーリングされたタイムスタンプコード化があるt巻きつけて着るドレス…12 4.4.3. スケーリングされたタイムスタンプコード化のためのアルゴリズム…12 4.5. _tをRecalculatingして、相殺してください…14 4.6. t_ストライドとTscは拡大3で弛みます…14 4.7. タイマベースの圧縮を使用します…15 5. 圧縮を記載してください…15 5.1. CSRCはRTPのダイナミックなチェーンで項目を記載します…15 5.2. 複数のCC分野発生…15 5.3. ビットはリストで圧縮にマスクをかけます…16 5.4. ヘッダーはリストで圧縮を圧縮しました…16 5.5. 超能力ヌルヘッダーリスト圧縮…17 5.6. IP拡張ヘッダーのための変換テーブルとインデックス…17 5.7. 参照リスト…17 5.8. そして、圧縮、ああ、GRE一連番号…18 6. 特性をアップデートします…19 6.1. 暗黙のアップデート…19 6.2. UO-1*の特性をアップデートします…20 6.3. IRパケットのために特性をアップデートする文脈…20 6.4. 拡大3におけるRTP詰め物分野(R-P)…20 6.5. RTP eXtensionはダイナミックな部分で(X)に噛み付きました…21 7. 文脈管理とCID/文脈Reuse…21 7.1. 減圧装置文脈の固執…21 7.2. Cid/文脈再利用…21 7.2.1. 同じプロフィールでCid/文脈を再利用します…22 7.2.2. 異なったプロフィールでCid/文脈を再利用します…23 8. 他のプロトコル明確化…23 8.1. NBOの意味…23
Jonsson, et al. Standards Track [Page 2] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
イェンソン、他 規格は2007年2月にRFC4815修正と明確化をRFC3095に追跡します[2ページ]。
8.2. IP-ID .....................................................23
8.3. Extension-3 in UOR-2* Packets .............................24
8.4. Multiple Occurrences of the M Bit .........................24
8.5. Multiple SN options in one feedback packet ................24
8.6. Multiple CRC Options in One Feedback Packet ...............25
8.7. Responding to Lost Feedback Links .........................25
8.8. UOR-2 in Profile 0x0002 (UDP) and Profile 0x0003 (ESP) ....25
8.9. Sequence Number LSB's in IP Extension Headers .............25
8.10. Expecting UOR-2 ACKs in O-Mode ...........................26
8.11. Context Repairs, TS_STRIDE and TIME_STRIDE ...............26
9. ROHC Negotiation ...............................................27
10. PROFILES Sub-option in ROHC-over-PPP ..........................27
11. Constant IP-ID Encoding in IP-only and UPD-Lite Profiles ......27
12. Security Considerations .......................................28
13. Acknowledgments ...............................................28
14. References ....................................................28
14.1. Normative References .....................................28
14.2. Informative References ...................................29
Appendix A. Sample CRC Algorithm ..................................30
8.2. IP-ID…23 8.3. UOR-2*パケットでの拡大-3…24 8.4. Mの複数の発生に噛み付きました…24 8.5. 1つのフィードバックパケットの複数のSNオプション…24 8.6. 1つのフィードバックパケットの複数のCRCオプション…25 8.7. 無くなっているフィードバックに応じるのはリンクされます…25 8.8. プロフィール0x0002のUOR-2(UDP)とプロフィール0x0003(超能力)…25 8.9. 一連番号LSBがIP拡張ヘッダーにあります…25 8.10. O-モードでUOR-2 ACKsを予想します…26 8.11. tの文脈修理、_ストライド、およびタイム誌_は大股で歩きます…26 9. ROHC交渉…27 10. ROHC過剰pppにおけるサブオプションのプロフィール…27 11. IPだけとUPD-Liteでプロフィールをコード化する一定のIP-ID…27 12. セキュリティ問題…28 13. 承認…28 14. 参照…28 14.1. 標準の参照…28 14.2. 有益な参照…29付録A.はCRCアルゴリズムを抽出します…30
1. Introduction and Terminology
1. 序論と用語
RFC 3095 [1] defines the RObust Header Compression (ROHC) framework and profiles for IP (Internet Protocol) [8][9], UDP (User Datagram Protocol) [10], RTP (Real-Time Transport Protocol) [11], and ESP (Encapsulating Security Payload) [12]. During implementation and interoperability testing of RFC 3095, some ambiguities and common misinterpretations have been identified, as well as a few errors.
RFC3095[1]はIP(インターネットプロトコル)[8][9]、UDP(ユーザー・データグラム・プロトコル)[10]、RTP(リアルタイムのTransportプロトコル)[11]、および超能力(Security有効搭載量を要約する)[12]のためのRObust Header Compression(ROHC)枠組みとプロフィールを定義します。 RFC3095の実現と相互運用性テストの間、いくつかのあいまいさと一般的な誤解は特定されています、いくつかの誤りと同様に。
This document summarizes identified issues and provides corrections needed for implementations of RFC 3095 to interoperate, i.e., it constitutes an update to RFC 3095. This document also provides other clarifications related to common misinterpretations of the specification. References to RFC 3095 should, therefore, also include this document.
このドキュメントは、特定された問題をまとめて、RFC3095の実現が共同利用するのに必要である修正を供給します、すなわち、それはRFC3095にアップデートを構成します。 また、このドキュメントは仕様の一般的な誤解に関連する他の明確化を提供します。 したがって、また、RFC3095の参照はこのドキュメントを含むべきです。
In addition, some clarifications and corrections are also provided for RFC 3241 (ROHC over PPP) [2], RFC 3843 (ROHC IP-only profile) [4], and RFC 4019 (ROHC UDP-Lite profiles) [5], which are thus also updated by this document. Furthermore, RFC 4362 (ROHC Link-Layer Assisted Profile) [7] is implicitly updated by this document, since RFC 4362 is also based on RFC 3095.
また、さらに、またこのドキュメントによってこのようにしてアップデートされるRFC3241(PPPの上のROHC)[2]、RFC3843(ROHC IPだけプロフィール)[4]、およびRFC4019(ROHC UDP-Liteプロフィール)[5]にいくつかの明確化と修正を提供します。 その上、このドキュメントでそれとなくRFC4362(ROHC Link-層のAssisted Profile)[7]をアップデートします、また、RFC4362がRFC3095に基づいているので。
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 [6].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[6]で説明されるように本書では解釈されることであるべきですか?
Jonsson, et al. Standards Track [Page 3] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
イェンソン、他 規格は2007年2月にRFC4815修正と明確化をRFC3095に追跡します[3ページ]。
When a section of this document makes formal corrections, additions or invalidations to text in RFC 3095, this is clearly summarized. The text from RFC 3095 that is being addressed is given and labeled "INCOMPLETE", "INCORRECT", or "INCORRECT AND INVALIDATED", followed by the correct text labeled "CORRECTED", where applicable. When text is added that does not simply correct text in previous specifications, it is given with the label "FORMAL ADDITION".
このドキュメントのセクションがRFCのテキストへの正式な修正、追加または無効を3095にすると、これは明確にまとめられます。 記述されているRFC3095からのテキストは、与えられていて、「不完全である」か、「不正確である」か、または「不正確、無効にされる」と分類されます、適切であるところで「直る」と分類された正しいテキストがあとに続いていて。 前の仕様でテキストを絶対に修正しないテキストを加えるとき、ラベル「正式な添加」と共にそれを与えます。
In this document, a reference to a section in RFC 3095 [1] is written as RFC 3095-Section <number>.
本書では、RFC3095[1]のセクションの参照は3095セクションのRFC<番号>として書かれています。
2. CRC Calculation and Coverage
2. CRC計算と適用範囲
2.1. CRC Calculation
2.1. CRC計算
RFC 3095-Section 5.9 defines polynomials for 3-, 7-, and 8-bit Cyclic Redundancy Checks (CRCs), but it does not specify what algorithm is used. The 3-, 7- and 8-bit CRCs are calculated using the CRC algorithm defined in [3].
RFC3095セクションの5.9は3、7、および8ビットのCyclic Redundancy Checks(CRCs)のために多項式を定義しますが、それは、どんなアルゴリズムが使用されているかを指定しません。 3、7、および8ビットのCRCsは、[3]で定義されたCRCアルゴリズムを使用することで計算されます。
A Perl implementation of the algorithm can be found in Appendix A of this document.
このドキュメントのAppendix AでアルゴリズムのPerl実現を見つけることができます。
2.2. Padding Octet and CRC Calculations
2.2. 八重奏とCRC計算を水増しします。
RFC 3095-Section 5.9.1 is incomplete, as it does not mention how to handle the padding octet in CRC calculations for IR and IR-DYN packets. Padding isn't meant to be a meaningful part of a packet and is not included in the CRC calculation. As a result, the CRC does not cover the Add-CID octet for CID 0, either.
RFC3095セクションの5.9.1は不完全です、どうIRとIR-DYNパケットのためのCRC計算における詰め物八重奏を扱うかに言及しないとき。 詰め物は、パケットの重要な一部であることは意味されないで、またCRC計算に含まれていません。 その結果、CRCはCID0のためにAdd-CID八重奏をカバーしていません。
INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.9.1):
不完全なRFC3095テキスト(RFC3095セクションの5.9.1):
"The CRC in the IR and IR-DYN packet is calculated over the entire
IR or IR-DYN packet, excluding Payload and including CID or any
Add-CID octet."
「IRとIR-DYNパケットのCRCは全体のIRかIR-DYNパケットの上で計算されます、有効搭載量とCIDかどんなAdd-CID八重奏も含んでいることを除いて。」
CORRECTED TEXT:
直っているテキスト:
"The CRC in the IR and IR-DYN packet is calculated over the entire
IR or IR-DYN packet, excluding Payload, Padding and including CID
or any Add-CID octet, except for the add-CID octet for CID 0."
「IRとIR-DYNパケットのCRCは全体のIRかIR-DYNパケットの上で計算されます、有効搭載量と、PaddingとCIDかどんなAdd-CID八重奏も含んでいることを除いて、CID0のためのCIDを加えている八重奏を除いて。」
Jonsson, et al. Standards Track [Page 4] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
イェンソン、他 規格は2007年2月にRFC4815修正と明確化をRFC3095に追跡します[4ページ]。
2.3. CRC Coverage in CRC Feedback Options
2.3. CRCフィードバックオプションにおけるCRC適用範囲
RFC 3095-Section 5.7.6.3 is incomplete, as it does not mention how the "size" field is handled when calculating the 8-bit CRC used in the CRC feedback option. Since the "size" field is an extension of the "code" field, it must be treated in the same way.
RFC、3095セクション、5.7 .6 .3は不完全です、CRCがCRCフィードバックオプションに使用した8ビットについて計算するとき、「サイズ」分野がどう扱われるかに言及しないとき。 「サイズ」分野が「コード」分野の拡大であるので、同様に、それを扱わなければなりません。
INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7.6.3):
不完全なRFC3095テキスト、(RFC3095セクションの5.7.6、.3):
"The CRC option contains an 8-bit CRC computed over the entire
feedback payload, without the packet type and code octet, but
including any CID fields, using the polynomial of section 5.9.1."
「CRCオプションはパケットタイプとコード八重奏なしで全体のフィードバックペイロードの上計算されますが、どんなCID分野も含む8ビットのCRCを含んでいます、セクション5.9.1の多項式を使用して。」
CORRECTED TEXT:
直っているテキスト:
"The CRC option contains an 8-bit CRC computed over the entire
feedback payload including any CID fields but excluding the
packet type, the 'Size' field and the 'Code' octet, using the
polynomial of Section 5.9.1."
「CRCオプションはどんなCID分野も含んでいますが、パケットタイプ、'サイズ'分野、および'コード'八重奏を遮断する全体のフィードバックペイロードの上計算された8ビットのCRCを含んでいます、セクション5.9.1の多項式を使用して。」
2.4. CRC Coverage of the ESP NULL Header
2.4. 超能力ヌルヘッダーのCRC適用範囲
RFC 3095-Section 5.8.7 gives the CRC coverage of the ESP NULL [13] header as "Entire ESP header". This must be interpreted as including only the initial part of the header (i.e., Security Parameter Index (SPI) and sequence number), and not the trailer part at the end of the payload. Therefore, the ESP NULL header has the same CRC coverage as the ESP header used in the ESP profile (RFC 3095-Section 5.7.7.7).
RFC3095セクションの5.8.7は「全体の超能力ヘッダー」としてESP NULL[13]ヘッダーのCRC適用範囲を与えます。 ペイロードの端にトレーラ部分ではなく、ヘッダー(すなわち、Security Parameter Index(SPI)と一連番号)の初期の一部だけを含んでいて、これを解釈しなければなりません。 したがって、ESP NULLヘッダーには超能力プロフィールで使用される超能力ヘッダーと同じCRC適用範囲がある、(RFC3095セクションの5.7.7、.7)。
3. Mode Transition
3. モード変遷
3.1. Feedback During Mode Transition to U- and O-Mode
3.1. Uへのモード変遷の間のフィードバックとO-モード
RFC 3095-Section 5.6.1 states that during mode transitions, while the D_TRANS parameter is I, the decompressor sends feedback for each received packet. This restrictive behavior prevents the decompressor from using a sparse feedback algorithm during mode transitions.
RFC3095セクションの5.6.1は、D_TRANSパラメタが私ですが、モード変遷の間減圧装置がそれぞれの容認されたパケットのためにフィードバックを送ると述べます。 この制限している振舞いは、減圧装置がモード変遷の間、まばらなフィードバックアルゴリズムを使用するのを防ぎます。
To reduce transmission overhead and computational complexity (including CRC calculation) associated with feedback packets sent for each decompressed packet during mode transition, a decompressor MAY be implemented with slightly modified mode transition procedures compared to those defined in [1], as described in this section.
それぞれの減圧されたパケットのためにモード変遷の間、送るフィードバックパケットに関連しているトランスミッションオーバーヘッドと計算量(CRC計算を含んでいる)を下げるために、[1]で定義されたものと比較されるモード変遷手順がわずかに変更されていた状態で、減圧装置は実行されるかもしれません、このセクションで説明されるように。
These enhanced procedures should be considered only as a possible improvement to a decompressor implementation, since interoperability is not affected in any way. A decompressor implemented according to
これらの高められた手順は減圧装置実現への可能な改良だけと考えられるべきです、相互運用性が何らかの方法で影響を受けないので。 減圧装置は実行しました。
Jonsson, et al. Standards Track [Page 5] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
イェンソン、他 規格は2007年2月にRFC4815修正と明確化をRFC3095に追跡します[5ページ]。
the optimized procedures will interoperate with an RFC 3095 compressor, as well as a decompressor implemented according to the procedures described in RFC 3095.
最適化された手順は3095年のRFCコンプレッサーで共同利用するでしょう、RFC3095で説明された手順によると、実行された減圧装置と同様に。
3.1.1. Mode Transition Procedures Allowing Sparse Feedback
3.1.1. まばらなフィードバックを許すモード変遷手順
The purpose of these enhanced transition procedures is to allow the decompressor to sparsely send feedback for packets decompressed during the second half of the transition procedure, i.e., after an appropriate IR/IR-DYN/UOR-2 packet has been received from the compressor. This is achieved by allowing the decompressor transition parameter (D_TRANS) to be set to P (Pending) at that stage, as shown in the transition diagrams of Sections 3.1.2 and 3.1.3 below.
これらの高められた変遷手順の目的は減圧装置が変遷手順の後半に減圧されたパケットのためにフィードバックをまばらに送るのを許容することです、すなわち、コンプレッサーから適切なIR IR/DYN/UOR-2パケットを受け取った後に。 減圧装置変遷パラメタ(D_TRANS)がその段階にPに(未定)で設定されるのを許容することによって、これは達成されます、セクション3.1 .2と3.1の変遷ダイヤグラムで.3未満を示しているように。
This enhanced transition, where feedback need not be sent for every decompressed packet, does however introduce some considerations in case feedback messages would be lost. Specifically, there is a risk for a deadlock situation when a transition from R-mode is performed; if no feedback message successfully reaches the compressor, the transition is never completed. For transition between U-mode and O-mode, there is also a small risk for reduced compression efficiency.
これは変遷を機能アップしました、フィードバックメッセージが失われるといけないでしょう、フィードバックがあらゆる減圧されたパケットのために送られなければならないというわけではなくて、したがって、しかしながら、いくつかの問題を紹介します。 R-モードから変化するとき、明確に、行き詰まり状況のためのリスクがあります。 どんなフィードバックメッセージも首尾よくコンプレッサーに達しないなら、変遷は決して終了していません。 また、U-モードとO-モードの間の変遷のために、減少している圧縮効率のための低いリスクがあります。
To avoid this, the decompressor MUST continue to send feedback at least periodically, as well as when in a Pending transition state. This is equivalent to enhancing the definition of the D_TRANS parameter in RFC 3095-Section 5.6.1, to include the definition of a Pending state:
これを避けるために、減圧装置は、少なくとも定期的、また、いつとしてPending変遷状態でフィードバックを送るか続けなければなりません。 これはPending状態の定義を含むようにRFC3095セクションの5.6.1とのD_TRANSパラメタの定義を機能アップするのに同等です:
- D_TRANS:
Possible values for the D_TRANS parameter are (I)NITIATED,
(P)ENDING, and (D)ONE. D_TRANS MUST be initialized to D, and a
mode transition can be initiated only when D_TRANS is D. While
D_TRANS is I, the decompressor sends a NACK or ACK carrying a CRC
option for each packet received. When D_TRANS is set to P, the
decompressor does not have to send a NACK or ACK for each packet
received, but it MUST continue to send feedback with some
periodicity, and all feedback packets sent MUST include the CRC
option. This ensures that all mode transitions will be completed
also in case of feedback losses.
- D_、移-、: D_TRANSパラメタのための可能な値は、(I)NITIATEDと、(P)ENDINGと、(D)ONEです。 Dに初期化してください。そうすれば、D_TRANSがD.であるときにだけ、モード変遷を開始できます。D_TRANS MUST、While D_TRANSが私である、減圧装置は各パケットのためのCRCオプションが受けたナックかACKキャリングを送ります。 何らかの周期性があるフィードバックを送り続けなければなりません、そして、D_TRANSがPに用意ができているとき、減圧装置がナックを送らなければならない必要はありませんか、各パケットのためのACKは受信しましたが、またはパケットが送ったすべてのフィードバックがCRCオプションを含まなければなりません。 これは、また、すべてのモード変遷がフィードバックの損失の場合に終了するのを確実にします。
The modifications affect transitions to Optimistic and Unidirectional modes of operation (i.e., the transitions described in RFC 3095- Section 5.6.5 and RFC 3095-Section 5.6.6) and make those transition diagrams more consistent with the diagram describing the transition to R-mode.
変更で、Optimisticへの変遷とUnidirectional運転モード(すなわち、RFC3095部5.6の.5とRFC3095セクションの5.6.6で説明された変遷)に影響して、それらの変遷ダイヤグラムはR-モードに変遷を説明するダイヤグラムと、より一致するようになります。
Jonsson, et al. Standards Track [Page 6] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
イェンソン、他 規格は2007年2月にRFC4815修正と明確化をRFC3095に追跡します[6ページ]。
3.1.2. Transition from Reliable to Optimistic Mode
3.1.2. 信頼できるモードから楽観的なモードまでの変遷
The enhanced procedure for transition from Reliable to Optimistic mode is shown below:
ReliableからOptimisticモードまでの変遷のための高められた手順は以下に示されます:
Compressor Decompressor
----------------------------------------------
| |
| ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = O | |
|->->->-+ IR/IR-DYN/UOR-2(SN,O) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_TRANS = P
|->-.. | D_MODE = O
| ACK(SN,O) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
| |
コンプレッサー減圧装置---------------------------------------------- | | | ACK(O)/NACK(O)+-<<-<、-| D_は移-私と等しいです。| +<<<<<<<+| C_は移-Pと等しいです。|、-、<-<<、-+ | C_モードはOと等しいです。| | |、-、>->>、-+ IR IR/ダイン/UOR-2(SN、O)| | +>>>>>>>+| |、-、>、-.. +->>->、-| D_は移-Pと等しいです。|、-、>、-.. | D_モードはOと等しいです。| ACK(SN、O)+-<<-<、-| | +<<<<<<<+| C_は移-Dと等しいです。|、-、<-<<、-+ | | | |、-、>->>、-+ UO-0、UO-1*| | +>>>>>>>+| | +->>->、-| D_は移-Dと等しいです。| |
Jonsson, et al. Standards Track [Page 7] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
イェンソン、他 規格は2007年2月にRFC4815修正と明確化をRFC3095に追跡します[7ページ]。
3.1.3. Transition to Unidirectional Mode
3.1.3. 単方向のモードへの変遷
The enhanced procedure for transition to Unidirectional mode is shown on the following figure:
Unidirectionalモードへの変遷のための高められた手順は以下の図の上に示されます:
Compressor Decompressor
----------------------------------------------
| |
| ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = U | |
|->->->-+ IR/IR-DYN/UOR-2(SN,U) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_TRANS = P
|->-.. |
| ACK(SN,U) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
| | D_MODE= U
コンプレッサー減圧装置---------------------------------------------- | | | ACK(U)/ナック(U)+-<<-<、-| D_は移-私と等しいです。| +<<<<<<<+| C_は移-Pと等しいです。|、-、<-<<、-+ | C_モードはUと等しいです。| | |、-、>->>、-+ IR IR/ダイン/UOR-2(SN、U)| | +>>>>>>>+| |、-、>、-.. +->>->、-| D_は移-Pと等しいです。|、-、>、-.. | | ACK(SN、U)+-<<-<、-| | +<<<<<<<+| C_は移-Dと等しいです。|、-、<-<<、-+ | | | |、-、>->>、-+ UO-0、UO-1*| | +>>>>>>>+| | +->>->、-| D_は移-Dと等しいです。| | D_モードはUと等しいです。
3.2. Feedback During Mode Transition
3.2. モード変遷の間のフィードバック
RFC 3095-Section 5.6.1 states that feedback is always used during mode transitions. However, the text then continues by making concrete applications of the rule in an inconsistent way, making it unclear when CRCs are used. Further, the text does not define how the compressor should act during mode transitions based on feedback not protected by CRCs, i.e., whether or not to carry out mode transition actions. The proper behavior from the compressor is to perform any action related to mode transitions only when the feedback is protected by the CRC option.
いつもフィードバックがそうであるモード変遷の間に使用されるRFC3095セクションの5.6.1の州。 しかしながら、そしてテキストは矛盾した道における、規則の具体的な応用をすることによって、続きます、CRCsが使用されているとき、それを不明瞭にして。 さらに、テキストはコンプレッサーがフィードバックに基づくモード変遷の間、どうキャリーに出かけているか否かに関係なく、すなわち、CRCsが保護されていないのに作動するはずであるかを定義しません。モード変遷動作。 コンプレッサーからの適切な振舞いはフィードバックがCRCオプションで保護されるときだけ、モード変遷に関連するどんな動作も実行することです。
INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.6.1):
不完全なRFC3095テキスト(RFC3095セクションの5.6.1):
"As a safeguard against residual errors, all feedback sent during
a mode transition MUST be protected by a CRC, i.e., the CRC
option MUST be used."
「見逃し誤りに対する安全装置として、CRCはモード変遷の間に送られたすべてのフィードバックを保護しなければなりません、すなわち、CRCオプションを使用しなければなりません。」
CORRECTED TEXT:
直っているテキスト:
"As a safeguard against residual errors, all feedback sent by the
decompressor during a mode transition MUST be protected by a CRC,
i.e., the CRC option MUST be used. The compressor MUST ignore
「見逃し誤りに対する安全装置として、CRCはモード変遷の間に減圧装置によって送られたすべてのフィードバックを保護しなければなりません、すなわち、CRCオプションを使用しなければなりません。」 コンプレッサーは無視されなければなりません。
Jonsson, et al. Standards Track [Page 8] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
イェンソン、他 規格は2007年2月にRFC4815修正と明確化をRFC3095に追跡します[8ページ]。
feedback information related to mode transition if the feedback
is not protected by the CRC option."
「フィードバックがCRCオプションで保護されないなら、フィードバック情報はモード変遷に関連しました。」
One more related issue that requires clarifications comes from the following text at the end of RFC 3095-Section 5.6.1:
明確化を必要とするもうひとつの関連する冊がRFC3095セクションの5.6.1の終わりの以下のテキストから来ます:
"While D_TRANS is I, the decompressor sends a NACK or ACK carrying
a CRC option for each received packet."
「D_TRANSは私ですが、減圧装置で、ナックかACKがそれぞれの容認されたパケットのためのCRCオプションを運びます。」
However, RFC 3095-Section 5.5.2.2 already stated that for R-mode, feedback is never sent for packets that do not update the context, i.e., for packets that do not carry a CRC, such as R-0 and R-1*.
しかしながら、文脈をアップデートしないパケットのために.2が既に述べた決してR-モード、フィードバックのためのそうでないRFC3095セクションの5.5.2を送って、すなわち、そうしないパケットに関してCRCを運んでください、R-0やR-1*のように。
This means that when D_TRANS=I during mode transition, a decompressor operating in R-mode sends an acknowledgement for each packet it receives and MUST use the sequence number that corresponds to the packet that last updated the context, i.e., the decompressor MUST NOT use the sequence number of the R-0 or the R-1* packet.
これは、D_TRANSがモード変遷の間、私と等しいと、R-モードで作動する減圧装置がそれが受ける各パケットのための承認を送って、文脈をアップデートしたパケットに対応する一連番号を使用しなければならなくて、すなわち、減圧装置がR-0かR-1*パケットの一連番号を使用してはいけないことを意味します。
3.3. Packet Decoding During Mode Transition
3.3. モード変遷の間に解読するパケット
The purpose of a mode transition is to ensure that the compressor and the decompressor coherently move from one mode of operation to another using a three-way handshake. At one point during the mode transition, the decompressor acknowledges the reception of one (or more) IR, IR-DYN or UOR-2 packet(s) that have mode bits set to the new mode. Packets of type 0 or type 1 that are received up to this point are decompressed using the old mode, while afterwards they are decompressed using the new mode. If the enhanced transition procedures described in Section 3.1 are used, the setting of the D_TRANS parameter to P represents this breakpoint. The successful decompression of a packet of type 0 or type 1 completes the mode transition.
モード変遷の目的はコンプレッサーと減圧装置が3方向ハンドシェイクを使用することで1つの運転モードから別の運転モードまで一致していて動くのを保証することです。 モード変遷の間の1つの時点では、減圧装置はモードビットを新型に設定する1(さらに)IR、IR-DYNまたはUOR-2パケットのレセプションを承認します。 この時点までに受け取られるタイプ0かタイプ1のパケットは古いモードを使用することで減圧されます、それらがその後、新型を使用することで減圧されますが。 セクション3.1で説明された高められた変遷手順が使用されているなら、PへのD_TRANSパラメタの設定はこの区切り点を表します。 タイプ0かタイプ1のパケットのうまくいっている減圧はモード変遷を終了します。
4. Timestamp Encoding
4. タイムスタンプコード化
4.1. Encoding Used for Compressed TS Bits
4.1. コード化は圧縮されたtにビットを使用しました。
RTP Timestamp (TS) values are always encoded using W-LSB encoding, both when sent scaled and unscaled. When no TS bits are transmitted in a compressed packet, TS is always scaled. If a compressed packet carries an Extension 3 and field(Tsc)=0, the compressed packet must thus always carry unscaled TS bits. For TS values sent in Extension 3, W-LSB encoded values are sent using the self-describing variable- length format (RFC 3095-Section 4.5.6), and this applies to both scaled and unscaled values.
RTP Timestamp(TS)値がW-LSBコード化を使用することでいつもコード化されて、送ると、両方が、比例して、非スケーリングされました。 TSビットが全く圧縮されたパケットで伝えられないとき、TSはいつもスケーリングされます。 圧縮されたパケットがExtension3と分野(Tsc)=0を運ぶなら、その結果、圧縮されたパケットはいつもunscaled TSビットを運ばなければなりません。 Extension3で送られたTS値のために、自己について説明する可変長さの形式(RFC3095セクションの4.5.6)を使用することでコード化された値を送って、これが両方に適用するW-LSBは値をスケーリングして、非スケーリングしました。
Jonsson, et al. Standards Track [Page 9] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
イェンソン、他 規格は2007年2月にRFC4815修正と明確化をRFC3095に追跡します[9ページ]。
4.2. (De)compression of TS without Transmitted TS Bits
4.2. (De)Transmitted TS BitsのないTSの圧縮
When ROHC RTP operates using its most efficient packet types, apart from packet type identification and the error detection CRC, only RTP sequence number (SN) bits are transmitted in RTP compressed headers. All other fields are then omitted either because they are unchanged or because they can be reconstructed through a function from the SN (i.e., by combining the transmitted SN bits with state information from the context). Fields that can be inferred from the SN are the IP Identification (IP-ID) and the RTP Timestamp (TS).
ROHC RTPがRTP一連番号(SN)ビットだけがパケットタイプ確認と誤り検出CRCは別として伝えられる最も有能なパケットタイプを使用することで作動するとき、RTPはヘッダーを圧縮しました。 そして、それらが変わりがないか、または機能を通してSN(すなわち、伝えられたSNビットを文脈からの州の情報に結合するのによる)からそれらは再建できるので、他のすべての分野が省略されます。 SNから推論できる分野は、IP Identification(IP-ID)とRTP Timestamp(TS)です。
IP-ID compression and decompression, both with and without transmitted IP-ID bits in the compressed header, are well defined in RFC 3095-Section 4.5.5 (see Section 8.2). For the TS field, however, RFC 3095 only defines how to decompress based on actual TS bits in the compressed header, either scaled or unscaled, but not how to infer the TS from the SN when there are no TS bits present in the compressed header.
IP-ID圧縮と減圧(圧縮されたヘッダーの伝えられたIP-IDビットのあるなしにかかわらず両方)はRFC3095セクションの4.5.5でよく定義されます(セクション8.2を見てください)。 しかしながら、圧縮されたヘッダーの現在のどんなTSビットもないときだけ、TS分野と、RFC3095はSNからTSをどう推論するかではなく、スケーリングされるか、または非スケーリングされた圧縮されたヘッダーの実際のTSビットに基づいて減圧する方法を定義します。
When no TS bits are received in the compressed header, the scaled TS value is reconstructed assuming a linear extrapolation from the SN, i.e., delta_TS = delta_SN * default-slope, where delta_SN and delta_TS are both signed integers. RFC 3095-Section 5.7 defines the potential values for default-slope.
圧縮されたヘッダーにTSビットを全く受け取らないとき、SNから直線的な推定を仮定しながら、スケーリングされたTS値を再建します、すなわち、デルタ_TSはデルタ_SN*デフォルトスロープ整数と等しいです。(そこでは、デルタ_SNとデルタ_TSがともにサインされます)。 RFC3095セクションの5.7はデフォルトスロープと潜在的価値を定義します。
INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7):
不完全なRFC3095テキスト(RFCの3095セクションの5.7):
"If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before
compression (see section 4.5.3), and default-slope(TS) = 1.
「値(Tsc)=1であるなら、Scaled RTP Timestampコード化は圧縮(セクション4.5.3を見る)、およびデフォルトスロープ(TS)=1の前に使用されます。」
If value(Tsc) = 0, the Timestamp value is compressed as-is, and
default-slope(TS) = value(TS_STRIDE)."
「(Tsc)=0を評価してください、Timestamp値がそのままで圧縮されて、デフォルトスロープ(TS)が値(TS_STRIDE)と等しいなら。」
CORRECTED TEXT:
直っているテキスト:
"When a compressed header with no TS bits is received, the scaled
TS value is reconstructed assuming a linear extrapolation from
the SN, i.e., delta_TS = delta_SN * default-slope(TS).
「TSビットのない圧縮されたヘッダーが受け取られているとき、スケーリングされたTS値はSNから直線的な推定を仮定しながら、再建されます、デルタ_SN*デフォルトスロープすなわち、デルタ_TS=(TS)。」
If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before
compression (see Section 4.5.3), and default-slope(TS) = 1.
値(Tsc)=1であるなら、Scaled RTP Timestampコード化は圧縮(セクション4.5.3を見る)、およびデフォルトスロープ(TS)=1の前に使用されます。
If value(Tsc) = 0, the Timestamp value is compressed as-is, and
default-slope(TS) = value(TS_STRIDE). If a packet with no TS
bits is received with Tsc = 0, the decompressor MUST discard the
packet."
値(Tsc)=0であるなら、Timestamp値はそのままで圧縮されます、そして、デフォルトスロープ(TS)は値(TS_STRIDE)と等しいです。 「Tsc=0でTSビットのないパケットを受け取るなら、減圧装置はパケットを捨てなければなりません。」
Jonsson, et al. Standards Track [Page 10] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
イェンソン、他 規格は2007年2月にRFC4815修正と明確化をRFC3095に追跡します[10ページ]。
INCORRECT AND INVALIDATED RFC 3095 TEXT (Section RFC 3095-5.5.1.2):
不正確なANDはRFC3095テキスト(セクションRFC3095-5.5.1.2)を無効にしました:
"For example, in a typical case where the string pattern has the
form of non-SN-field = SN * slope + offset, one ACK is enough if
the slope has been previously established by the decompressor
(i.e., only the new offset needs to be synchronized). Otherwise,
two ACKs are required since the decompressor needs two headers to
learn both the new slope and the new offset."
Consequently, there is no other slope value than the default-slope, as defined in RFC 3095-Section 5.7.
4.3. Interpretation Intervals for TS Encoding
RFC 3095-Section 4.5.4 defines the interpretation interval, p, for timer-based compression of the RTP timestamp. However, RFC 3095- Section 5.7 defines a different interpretation interval, which is defined as the interpretation interval to use for all TS values. It is thus unclear which p-value to use, at least for timer-based compression.
The way this should be interpreted is that the p-value differs depending on whether or not timer-based compression is enabled.
For timer-based compression (TIME_STRIDE set to a non-zero value), the interpretation interval is:
p = 2^(k-1) - 1 (as per RFC 3095-Section 4.5.4)
Otherwise, the interpretation interval is:
p = 2^(k-2) - 1 (as per RFC 3095-Section 5.7)
4.4. Scaled RTP Timestamp Encoding
This section redefines the algorithm for scaled RTP timestamp encoding, defined as a 5-step procedure in RFC 3095-Section 4.5.3. Two formal errors have been corrected, as described in sub-sections 4.4.1 and 4.4.2 below, and the whole algorithm has been reworked to be more concise and to use well-defined terminology. The resulting text can be found in 4.4.3 below.
4.4.1. TS_STRIDE for Scaled Timestamp Encoding
RFC 3095 defines the timestamp stride (TS_STRIDE) as the expected increase in the timestamp value between two RTP packets with consecutive sequence numbers. TS_STRIDE is set by the compressor and
Jonsson, et al. Standards Track [Page 11] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
explicitly communicated to the decompressor, and it is used as the scaling factor for scaled TS encoding.
The relation between TS and TS_SCALED, given by the following equality in RFC 3095-Section 4.5.3, defines the mathematical meaning of TS_STRIDE:
TS = TS_SCALED * TS_STRIDE + TS_OFFSET
TS_SCALED is incompletely written as TS / TS_STRIDE in the compression step following the above core equality. This formula is incorrect both because it excludes TS_OFFSET and because it would prevent a TS_STRIDE value of 0, which is an alternative not excluded by the definition or by the core equality above. If "/" were a generally unambiguously defined operation meaning "the integral part of the result from dividing X by Y", the absence of TS_OFFSET could be explained, but the formula would still lack a proper output for TS_STRIDE equal to 0. The formula of "2. Compression" is thus valid only with the following requirements:
a) "/" means "the integral part of the result from dividing X by Y"
b) TS_STRIDE>0 (TS is never sent scaled when TS_STRIDE=0)
4.4.2. TS Wraparound with Scaled Timestamp Encoding
RFC 3095-Section 4.5.3 states in points 4 and 5 that the compressor is not required to initialize TS_OFFSET at wraparound, but that it is required to increase the number of bits sent for the scaled TS value when there is a TS wraparound. The decompressor is also required to detect and cope with TS wraparound, including updating TS_OFFSET.
This method is not interoperable and not robust. The gain is also insignificant, as TS wraparound happens very seldomly. Therefore, the compressor should reinitialize TS_OFFSET upon TS wraparound, by sending an unscaled TS.
4.4.3. Algorithm for Scaled Timestamp Encoding
INCORRECT RFC 3095 TEXT (RFC 3095-Section 4.5.3):
"1. Initialization: The compressor sends to the decompressor the
value of TS_STRIDE and the absolute value of one or several TS
fields. The latter are used by the decompressor to initialize
TS_OFFSET to (absolute value) modulo TS_STRIDE. Note that
TS_OFFSET is the same regardless of which absolute value is
used, as long as the unscaled TS value does not wrap around;
see 4) below.
Jonsson, et al. Standards Track [Page 12] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
2. Compression: After initialization, the compressor no longer
compresses the original TS values. Instead, it compresses the
downscaled values: TS_SCALED = TS / TS_STRIDE. The compression
method could be either W-LSB encoding or the timer-based
encoding described in the next section.
3. Decompression: When receiving the compressed value of
TS_SCALED, the decompressor first derives the value of the
original TS_SCALED. The original RTP TS is then calculated as
TS = TS_SCALED * TS_STRIDE + TS_OFFSET.
4. Offset at wraparound: Wraparound of the unscaled 32-bit TS will
invalidate the current value of TS_OFFSET used in the equation
above. For example, let us assume TS_STRIDE = 160 = 0xA0 and
the current TS = 0xFFFFFFF0. TS_OFFSET is then 0x50 = 80.
Then if the next RTP TS = 0x00000130 (i.e., the increment is
160 * 2 = 320), the new TS_OFFSET should be 0x00000130 modulo
0xA0 = 0x90 = 144. The compressor is not required to re-
initialize TS_OFFSET at wraparound. Instead, the decompressor
MUST detect wraparound of the unscaled TS (which is trivial)
and update TS_OFFSET to TS_OFFSET = (Wrapped around unscaled
TS) modulo TS_STRIDE"
CORRECTED TEXT:
"1. Initialization and updating of RTP TS scaling function: The
compressor sends to the decompressor the value of TS_STRIDE
along with an unscaled TS. These are both needed by the
decompressor to initialize TS_OFFSET as hdr(TS) modulo
field(TS_STRIDE). Note that TS_OFFSET is the same for any TS
as long as TS_STRIDE does not change and as long as the
unscaled TS value does not wrap around; see 4) below.
2. Compression: After initialization, the compressor no longer
compresses the unscaled TS values. Instead, it compresses the
scaled values. The compression method can be either W-LSB
encoding or timer-based encoding.
3. Decompression: When receiving a (compressed) TS_SCALED, the
field is first decompressed, and the unscaled RTP TS is then
calculated as TS = TS_SCALED * TS_STRIDE + TS_OFFSET.
4. Offset at wraparound: If the value of TS_STRIDE is not equal to
a power of two, wraparound of the unscaled 32-bit TS will
change the value of TS_OFFSET. When this happens, the
compressor SHOULD reinitialize TS_OFFSET by sending unscaled
TS, as in 1 above."
Jonsson, et al. Standards Track [Page 13] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
INCORRECT AND INVALIDATED RFC 3095 TEXT (RFC 3095-Section 4.5.3):
The entire point 5, i.e. the entire text starting from "5.
Interpretation interval at wraparound ...", down to and including
the block of text that starts with "Let a be the number of LSBs"
and that ends with "...interpretation interval is b." is incorrect
and is thus invalid.
4.5. Recalculating TS_OFFSET
TS can be sent unscaled if the TS value change does not match the established TS_STRIDE, but the TS_STRIDE might still stay unchanged. To ensure correct decompression of subsequent packets, the decompressor MUST therefore always recalculate TS_OFFSET (RTP TS modulo TS_STRIDE) when a packet with an unscaled TS value is received.
4.6. TS_STRIDE and the Tsc Flag in Extension 3
The Tsc flag in Extension 3 indicates whether or not TS is scaled. The value of the Tsc flag thus applies to all TS bits, as well as if there are no TS bits in the extension itself. When TS is scaled, it is always scaled using context(TS_STRIDE). The legend for Extension 3 in RFC 3095-Section 5.7.5 incorrectly states that value(TS_STRIDE) is used for scaled TS.
If TS_STRIDE is present in Extension 3, as indicated by the Tss flag being set, the compressed header SHOULD carry unscaled TS bits; i.e., the Tsc flag SHOULD NOT be set when Tss is set since an unscaled TS is needed together with TS_STRIDE to recalculate the TS_OFFSET. If TS_STRIDE is included in a compressed header with scaled TS, the decompressor must ignore and discard field(TS_STRIDE).
INCORRECT RFC 3095 TEXT (RFC 3095-Section 5.7.5):
"Tsc: Tsc = 0 indicates that TS is not scaled;
Tsc = 1 indicates that TS is scaled according to section
4.5.3, using value(TS_STRIDE).
Context(Tsc) is always 1. If scaling is not desired, the
compressor will establish TS_STRIDE = 1."
CORRECTED TEXT:
"Tsc: Tsc = 0 indicates that TS is not scaled;
Tsc = 1 indicates that TS is scaled according to Section
4.5.3, using context(TS_STRIDE).
Jonsson, et al. Standards Track [Page 14] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
Context(Tsc) is always 1. If scaling is not desired, the
compressor will establish TS_STRIDE = 1.
If field(Tsc) = 1, and if TSS = 1 (meaning that TS_STRIDE is
present in the extension), field(TS_STRIDE) MUST be ignored
and discarded."
When the compressor re-establishes a new value for TS_STRIDE using Extension 3, it should send unscaled TS bits together with TS_STRIDE.
4.7. Using Timer-Based Compression
Timer-based compression of the RTP timestamp, as described in RFC 3095-Section 4.5.4, may be used to reduce the number of transmitted timestamp bits (bytes) needed when the timestamp cannot be inferred from the SN. Timer-based compression is only used for decompression of compressed headers that contains a TS field; otherwise, when no timestamp bits are present, the timestamp is linearly inferred from the SN (see Section 4.2 of this document).
Whether or not to use timer-based compression is controlled by the TIME_STRIDE control field, which can be set by either an IR, an IR- DYN, or a compressed packet with Extension 3. Before timer-based compression can be used, the decompressor has to inform the compressor (on a per-channel basis) about its clock resolution by sending a CLOCK feedback option for any CID on the channel. The compressor can then initiate timer-based compression by sending (on a per-context basis) a non-zero TIME_STRIDE to the decompressor. When the compressor is confident that the decompressor has received the TIME_STRIDE value, it can switch to timer-based compression.
5. List Compression
5.1. CSRC List Items in RTP Dynamic Chain
RFC 3095-Section 5.7.7.6 defines the static and dynamic parts of the RTP header. This section indicates a 'Generic CSRC list' field in the dynamic chain, which has a variable length (see RFC 3095-Section 5.8.6). This field is always at least one octet in size, even if the list is empty (as opposed to the CSRC list in the uncompressed RTP header, which is not present when the RTP CC field is set to 0).
5.2. Multiple Occurrences of the CC Field
The static and the dynamic parts of the RTP header are defined in RFC 3095-Section 5.7.7.6. In the dynamic part, a CC field indicates the number of CSRC items present in the 'Generic CSRC list'. Another CC field also appears within the 'Generic CSRC list' (RFC 3095-Section
Jonsson, et al. Standards Track [Page 15] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
5.8.6.1), because Encoding Type 0 is always used in the dynamic chain. Both CC fields have the same meaning: the value of the CC field determines the number of XI items in the CSRC list for Encoding Type 0, and it is not used otherwise. Therefore, the following applies:
FORMAL ADDITION TO RFC 3095:
"The first octet in the dynamic part of the RTP header contains a
CC field, as defined in Section 5.7.7.6. A second occurrence
appears in the 'Generic CSRC list', which is also in the dynamic
part of the RTP header, where Encoding Type 0 is used according
to the format defined in RFC 3095-5.8.6.1.
The compressor MUST set both occurrences of the CC field to the
same value.
The decompressor MUST use the value of the CC field from the
Encoding Type 0 within the Generic CRSC list, and it MUST thus
ignore the first occurrence of the CC field."
5.3. Bit Masks in List Compression
The insertion and/or removal schemes, described in RFC 3095-Sections 5.8.6.2 - 5.8.6.4, use bit masks to indicates insertion or removal positions within the reference list. The size of the bit mask can be 7 bits or 15 bits.
The compressor MAY use a 7-bit mask, even if the reference list has more than seven items, provided that changes to the list are only applied to items within the first seven items of the reference list, leaving items with an index not covered by the 7-bit mask unchanged. The decompressor MUST NOT modify items with an index not covered by the 7-bit mask, when a 7-bit mask is received for a reference list that contains more than seven items.
5.4. Headers Compressed with List Compression
In RFC 3095-Section 5.8, it states that headers that can be part of extension header chains "include" AH [14], ESP NULL [13], minimal encapsulation (MINE) [15], GRE [16][17], and IPv6 [9] extensions. This list of headers that can be compressed is correct, but the word "include" should not be there, since only the header types listed can actually be handled. It should further be noted that for the Minimal Encapsulation (MINE) header, there is no explicit discussion of how to compress it, as the header is sent either uncompressed or fully compressed away.
Jonsson, et al. Standards Track [Page 16] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
5.5. ESP NULL Header List Compression
Due to the offset of the fields in the trailer part of the ESP header, a compressor MUST NOT compress packets containing more than one NULL ESP [13] header, unless the second-outermost header is treated as a regular ESP [12] header and the packets are compressed using profile 0x0003.
5.6. Translation Tables and Indexes for IP Extension Headers
RFC 3095-Section 5.8.4 describes how list indexes are associated to list items and how table lists are built for IP extension headers. The text incorrectly states that one index per type is used, since the same type can appear several times with different content in one single chain.
In IP extension header list compression, an index is associated with each individual extension header of an extension header chain. When there are multiple non-identical occurrences of the same extension type (Protocol Number) within a header chain, each MUST be given its own index.
In the case where there are multiple identical occurrences of the same extension type, the compressor can associate them to the same index. When the value of an item whose index occurs more than once in the list is updated, the compressor MUST send the value for each occurrence of that index in the list.
When content of extension headers changes, an implementation can choose to either use a different index or update the existing one. Some extensions can be compressed away even when some fields change, as those changes can be conveyed to the decompressor implicitly (e.g. sequence numbers in extension headers that can be inferred from the RTP SN) or explicitly (e.g., as part of the 'IP extension header(s)' field in Extension 3).
When there is more than one IP header, there is more than one list of extension headers, and a translation table is maintained for each list independently of one another.
5.7. Reference List
A list compressed using encoding type 1 (insertion), type 2 (removal), or type 3 (removal/insertion) uses a coding scheme that is based on the use of a reference list in the context (identified as ref_id).
Jonsson, et al. Standards Track [Page 17] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
While it could seem to be a fair choice to send a type 1 list when ref_id is an empty list, there is nothing gained in doing so with respect to using a type 0 list. Sending a type 2 list when ref_id is an empty list would lead to a failure, while sending a type 3 list has very little meaning. All these alternatives could be seen as possible, based on how list compression is specified in RFC 3095.
If these alternatives were allowed, a decompressor would become required to maintain a sliding window of ref_id lists in R-mode, even for the case where no items are sent in the compressed list, and this is not a desirable requirement. Using list encoding type 1, type 2, and type 3 is therefore only allowed for non-empty reference lists.
FORMAL ADDITION TO RFC 3095:
"Regardless of the operating mode, for list encoding of type 1,
type 2, and type 3 lists, ref_id MUST refer to a non-empty list."
5.8. Compression of AH and GRE Sequence Numbers
RFC 3095-Section 5.8.4.2 and RFC 3095-Section 5.8.4.4 describe how to compress the Authentication Header (AH) [14] and the Generic Routing Encapsulation (GRE) [16][17] header. Both these sections present a possibility to omit the AH/GRE sequence number in the compressed header, under certain circumstances. However, the specific conditions for omitting the AH/GRE sequence number, as well as the concrete compression and decompression procedures to apply, are not clearly defined to guarantee robustness and facilitate interoperable implementation.
Proper rules are provided for the ESP case, i.e.,:
"Sequence Number: Not sent when the offset from the sequence
number of the compressed header is constant, when the compressor
has confidence that the decompressor has established the correct
offset. When the offset is not constant, the sequence number may
be compressed by sending LSBs"
The same logic applies to the AH/GRE sequence numbers.
INCORRECT RFC 3095 TEXT (RFC 3095-Section 5.8.4.2):
"If the sequence number in the AH linearly increases as the RTP
Sequence Number increases, and the compressor is confident that
the decompressor has obtained the pattern, the sequence number in
AH need not be sent. The decompressor applies linear
extrapolation to reconstruct the sequence number in the AH."
Jonsson, et al. Standards Track [Page 18] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
CORRECTED TEXT:
"The AH sequence number can be omitted from the compressed header
when the offset from the sequence number (SN) of the compressed
header is constant, when the compressor has confidence that the
decompressor has established the correct offset."
INCORRECT RFC 3095 TEXT (RFC 3095-Section 5.8.4.4):
"If the sequence number in the GRE header linearly increases as
the RTP Sequence Number increases and the compressor is confident
that the decompressor has received the pattern, the sequence
number in GRE need not be sent. The decompressor applies linear
extrapolation to reconstruct the sequence number in the GRE
header."
CORRECTED TEXT:
"The GRE sequence number can be omitted from the compressed header
when the offset from the sequence number (SN) of the compressed
header is constant, when the compressor has confidence that the
decompressor has established the correct offset."
6. Updating Properties
6.1. Implicit Updates
A context updating packet that contains compressed sequence number information may also carry information about other fields; in such cases, these fields are updated according to the content of the packet. The updating packet also implicitly updates inferred fields (e.g., RTP Timestamp) according to the current mode and the appropriate mapping function of the updated and inferred fields.
An updating packet thus updates the reference values of all header fields, either explicitly or implicitly, except for the UO-1-ID packet (see Section 6.2 of this document). In UO-mode, all packets are updating packets, while in R-mode, all packets with a CRC are updating packets.
For example, a UO-0 packet contains the compressed RTP sequence number (SN). Such a packet also implicitly updates RTP timestamp, IPv4 ID, and sequence numbers of IP extension headers.
Jonsson, et al. Standards Track [Page 19] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
6.2. Updating Properties of UO-1*
RFC 3095-Section 5.7.3 states that the values provided in extensions carried by a UO-1-ID packet do not update the context, except for SN, TS, or IP-ID fields. However, RFC 3095-Section 5.8.1 correctly states that the translation table in the context is updated whenever an (Index, item) pair is received, something that is contradicted by the statement in RFC 3095-5.7.3 because the UO-1-ID packet can carry Extension 3 with (Index, item) pair items within the 'Compressed CSRC list' field. In addition to this contradiction, the text does not mention what to do with the other sequence numbers inferred from the SN, which are also to be implicitly updated. The updating properties of UO-1* as stated by RFC 3095-Section 5.7.3 are thus incomplete.
INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7.3):
"Values provided in extensions, except those in other SN, TS, or
IP-ID fields, do not update the context."
CORRECTED TEXT:
"UO-1-ID packets only updates TS, SN, IP-ID, and sequence numbers
of IP extension headers. Other values provided in extensions do
not update the context.
The decompressor MUST update its translation table whenever an
(Index, item) pair is received, as per RFC 3095-Section 5.8.1,
and this rule applies also to UO-1-ID packets."
6.3. Context Updating Properties for IR Packets
IR packets do not clear the whole context, but update all fields carried in the IR header. Similarly, an IR without a dynamic chain simply updates the static part of the context, while the rest of the context is left unchanged.
A consequence of this is that fields that are not updated by the IR packet, e.g., the translation tables for list compression, MUST NOT be invalidated by the decompressor when it assumes context damage.
6.4. RTP Padding Field (R-P) in Extension 3
RFC 3095-Section 5.7.5 defines the properties of RTP header flags and fields in Extension 3. These get updated when the rtp flag of the Extension 3 is set, i.e., when rtp = 1; otherwise, they are not updated. However, it is unclear how Extension 3 updates the R-P bit in the context.
Jonsson, et al. Standards Track [Page 20] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7.5):
"R-P: RTP Padding bit, absolute value (presumed zero if absent)."
CORRECTED TEXT:
"R-P: RTP Padding bit. If R-PT = 1, R-P is the absolute value of
the RTP padding bit and this value updates context(R-P). If
R-PT = 0, context(R-P) is updated to zero."
6.5. RTP eXtension bit (X) in dynamic part
RFC 3095-Section 5.7.7.6 defines the properties of the RTP header flags and fields in the RTP part of the dynamic chain of IR and IR- DYN packets. However, it is unclear how the X bit is updated in the context.
RFC、3095セクション、5.7 .7 .6 IRとIR DYNパケットのダイナミックなチェーンのRTP部分のRTPヘッダー旗と分野の特性を定義します。 しかしながら、文脈でどのようにXビットをアップデートするかは不明瞭です。
INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7.7.6):
不完全なRFC3095テキスト、(RFC3095セクションの5.7.7、.6):
"X: Copy of X bit from RTP header (presumed 0 if RX = 0)"
「X:」 「RTPヘッダー(RX=0であるなら0であると推定される)から噛み付かれたXのコピー」
CORRECTED TEXT:
直っているテキスト:
"X: X bit from RTP header. If RX = 1, X is the X bit from the RTP
header and this value updates context(X). If RX = 0,
context(X) is updated to zero."
「X:」 XにRTPヘッダーから噛み付きました。 RX=1、XがRTPヘッダーからXビット単位で離れたところにあって、この値は文脈(X)をアップデートします。 「RX=0であるなら、文脈(X)をゼロにアップデートします。」
7. Context management and CID/context Reuse
7. 文脈管理とCID/文脈Reuse
7.1. Persistence of Decompressor Contexts
7.1. 減圧装置文脈の固執
As part of the negotiated channel parameters, compressor and decompressor have, through the MAX_CID parameter, agreed on the highest context identification (CID) number to be used. By agreeing on MAX_CID, the decompressor also agrees to provide memory resources to host at least MAX_CID+1 contexts, and an established context with a CID within this negotiated space MUST be kept by the decompressor until either the CID gets reused, or the channel is taken down or renegotiated.
交渉されたチャンネルパラメタの一部として、コンプレッサーと減圧装置は、使用されるためにMAX_CIDパラメタを通して最も高い文脈識別(CID)番号に同意しました。 MAX_CIDに同意することによって、また、減圧装置は、少なくともMAX_CID+1文脈をホスティングするためにメモリリソースを提供するのに同意して、CIDが再利用されるか、またはチャンネルが降ろされるか、再交渉されるまで、減圧装置でこの交渉されたスペースの中にCIDがある確立した関係を保たなければなりません。
7.2. CID/Context Reuse
7.2. Cid/文脈再利用
As part of the channel negotiation, the maximal number of active contexts supported is negotiated between the compressor and the decompressor through the MAX_CID parameter. The value of MAX_CID can differ significantly from one link application to another, as well as the load in terms of the number of packet streams to compress. The lifetime of a ROHC channel can also vary, from almost permanent to
チャンネル交渉の一部として、支持されたアクティブな文脈の最大限度の数はMAX_CIDパラメタを通してコンプレッサーと減圧装置の間で交渉されます。 MAX_CIDの値は1つのリンクアプリケーションから別のアプリケーションまで有意差がある場合があります、圧縮するパケットの流れの数に関する負荷と同様に。 また、ROHCチャンネルの寿命はほとんど永久的であるのと異なることができます。
Jonsson, et al. Standards Track [Page 21] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
イェンソン、他 規格は2007年2月にRFC4815修正と明確化をRFC3095に追跡します[21ページ]。
rather short-lived. However, in general, it is not expected that resources will be allocated for more contexts than what can reasonably be expected to be active concurrently over the link. As a consequence hereof, context identifiers (CIDs) and context memory are resources that will have to be reused by the compressor as part of what can be considered normal operation.
かなり短命です。 しかしながら、一般に、リソースが何が同時にリンクの上にアクティブであると合理的に予想できるかより多くの文脈のために割り当てられないと予想されます。 これの結果として、文脈識別子(CIDs)と文脈メモリは通常の操作であると考えることができることに関する部分としてコンプレッサーによって再利用されなければならないリソースです。
How context resources are reused is left unspecified in RFC 3095 [1] and subsequent 3095-based ROHC specifications. This document does not intend to change that, i.e., ROHC resource management is still considered an implementation detail. However, reusing a CID and its allocated memory is not always as simple as initiating a context with a previously unused CID. Because some profiles can be operating in various modes where packet formats vary depending on current mode, care has to be taken to ensure that the old context data will be completely and safely overwritten, eliminating the risk of undesired side effects from interactions between old and new context data. This document therefore points out some important core aspects to consider when implementing resource management in ROHC compressors and decompressors.
文脈リソースがどう再利用されるかはRFC3095[1]とその後の3095年のベースのROHC仕様で不特定のままにされます。 このドキュメントはそれを変えないつもりです、すなわち、ROHC資源管理は実現の詳細であるとまだ考えられています。 しかしながら、CIDとその割り当てられたメモリを再利用するのは以前に未使用のCIDと共に文脈を開始するのといつも同じくらい簡単ではありません。 いくつかのプロフィールが現在のモードによって、パケット・フォーマットが異なる様々なモードで作動できるので、古い文脈データが完全に安全に上書きされるのを保証するために注意しなければなりません、古くて新しい文脈データの間の相互作用からの望まれない副作用の危険を排除して。 したがって、このドキュメントは、ROHCコンプレッサーと減圧装置における資源管理を実行すると考えるためにいくつかの重要なコア局面を指摘します。
On a high level, CID/context reuse can be of two kinds, either reuse for a new context based on the same profile as the old context, or for a new context based on a different profile. These cases are discussed separately in the following two sub-sections.
高いレベルでは、CID/文脈再利用は2種類、古い背景と同じプロフィールに基づく新しい関係、または異なったプロフィールに基づく新しい関係のための再利用のものであることができます。 別々に以下の2つの小区分でこれらのケースについて議論します。
7.2.1. Reusing a CID/Context with the Same Profile
7.2.1. 同じプロフィールでCid/文脈を再利用します。
For multi-mode profiles, such as those defined in RFC 3095 [1], mode transitions are performed using a decompressor-initiated handshake procedure, as defined in RFC 3095-Section 5.6. When a CID/context is reused for a new context based on the same profile as the old context, the current mode of operation SHOULD be inherited from the old to the new context. Specifically, the compressor SHOULD continue to operate using the mode of operation of the old context also with the new context. The reason for this is that there is no reliable way for the compressor to inform the decompressor that a CID/context reuse is happening. The decompressor can thus not be expected to clear the context memory for the CID (see Section 6.3), and there is no way to trigger a safe mode switching (which requires the decompressor-initiated handshake procedure).
RFC3095[1]で定義されたものなどのマルチモードプロフィールに関しては、減圧装置で開始している握手手順を用いることでモード変化をします、RFCの3095セクションの5.6で定義されるように。 CID/文脈が再利用されたら、古い背景、操作SHOULDの現在のモードと同じプロフィールに基づく新しい関係に関して老人の関係から新しい関係まで引き継がれてください。 コンプレッサーSHOULDは、明確に、新しい関係をもっても古い背景の運転モードを使用することで作動し続けています。 この理由はコンプレッサーがCID/文脈再利用が起こっていることを減圧装置に知らせるどんな信頼できる方法もないということです。 その結果、減圧装置がCIDのための文脈メモリをクリアすることを期待できないで(セクション6.3を見てください)、安全なモードの切り換え(減圧装置で開始している握手手順を必要とする)の引き金となる方法が全くありません。
The rule of mode inheritance applies also when the CONTEXT_REINITIALIZATION signal (RFC 3095-Section 6.3.1) is used to reinitiate an entire context.
また、CONTEXT_REINITIALIZATION信号(RFC3095セクションの6.3.1)が全体の文脈を再開始するのに使用されるとき、モード遺産の規則は適用されます。
Jonsson, et al. Standards Track [Page 22] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
イェンソン、他 規格は2007年2月にRFC4815修正と明確化をRFC3095に追跡します[22ページ]。
7.2.2. Reusing a CID/Context with a Different Profile
7.2.2. 異なったプロフィールでCid/文脈を再利用します。
When a CID is reused for a new context based on a different profile than the old context, both the compressor and the decompressor MUST start operation with that context in the initial mode of the profile (if it is a multi-mode profile). This applies both to IR-initiated new contexts and profile downgrades with IR-DYN (e.g., the profile 0x0001 -> profile 0x0002 downgrade in RFC 3095-Section 5.11.1).
CIDが異なったプロフィールに基づく新しい関係のために古い背景より再利用されるとき、コンプレッサーと減圧装置の両方がプロフィールの初期のモードによるその文脈から操業を開始しなければなりません(それがマルチモードプロフィールであるなら)。 これはIR-DYN(例えば、RFC3095セクションの5.11.1におけるプロフィール0×0001->プロフィール0x0002ダウングレード)と共にIRで開始している新しい関係とプロフィールダウングレードに適用されます。
Type 0 and type 1 packets have different formats in U/O- and R-mode, and these R-mode packets have no CRC. When initiating a new context on a reused R-mode CID, there is a risk that the decompressor will misinterpret compressed packets if the initiating IR packets are lost.
0をタイプして、タイプ1パケットはU/Oの異なった形式とR-モードを持っています、そして、これらのR-モードパケットには、CRCが全くありません。 再利用されたR-モードCIDに関する新しい関係を開始するとき、開始しているIRパケットが無くなると減圧装置が圧縮されたパケットを誤解するというリスクがあります。
A CID for a context currently operating in R-mode SHOULD therefore not be reused for a new context based on a different profile than the old context. A compressor doing otherwise should minimize the risk for misinterpretation of R-0/R-1 by, e.g., not using packets of types beginning with 00 or 10 before it is highly confident that the new context has successfully been initiated at the decompressor.
CID、したがって、現在R-モードSHOULDで作動する文脈に関しては、異なったプロフィールに基づく新しい関係には、古い背景ほど再利用されないでください。 別の方法でするのがR-0/R-1の誤解のための危険を最小にするべきであるコンプレッサー、例えば、それの前の00か10で始まるタイプのパケットを使用しないのは新しい関係が減圧装置で首尾よく開始されたと非常に確信しています。
8. Other Protocol Clarifications
8. 他のプロトコル明確化
8.1. Meaning of NBO
8.1. NBOの意味
In IPv4 dynamic part (RFC 3095-Section 5.7.7.4), if the 'NBO' bit is set, it means that network byte order is used.
IPv4のダイナミックな部分、(RFC、3095セクション、5.7 .7 .4) 'NBO'ビットが設定されるなら、それは、ネットワークバイトオーダーが使用されていることを意味します。
8.2. IP-ID
8.2. IP-ID
According to RFC 3095-Section 5.7, IP-ID means the compressed value of the IPv4 header's 'Identification' field. Compressed packets contain this compressed value (IP-ID), while IR packets with dynamic chain and IR-DYN packets transmit the original, uncompressed Identification field value. The IP-ID field always represents the Identification value of the innermost IPv4 header whose corresponding RND flag is not 1.
RFCの3095セクションの5.7に従って、IP-IDはIPv4ヘッダーの'識別'分野の圧縮された値を意味します。 圧縮されたパケットはこの圧縮された値(IP-ID)を含んでいます、ダイナミックなチェーンとIR-DYNパケットがあるIRパケットはオリジナルの、そして、解凍されたIdentification分野価値を送りますが。 IP-ID分野はいつも対応するRND旗が1でない最も奥深いIPv4ヘッダーのIdentification値を表します。
If RND or RND2 is set to 1, the corresponding IP-ID(s) is (are) sent as 16-bit uncompressed Identification value(s) at the end of the compressed base header, according to the IP-ID description (see the beginning of RFC 3095-Section 5.7). When there is no compressed IP- ID, i.e., for IPv6 or when all IP Identification information is sent as is (as indicated by RND/RND2 being set to 1), the decompressor ignores IP-ID bits sent within compressed base headers.
RNDかRND2が1に用意ができているなら、16ビットの解凍されたIdentificationが圧縮されたベースヘッダーの端で(s)を評価するとき、対応するIP-IDを送ります(あります)、IP-ID記述によると(RFCの3095セクションの5.7の始まりを見てください)。 圧縮されたIP IDが全くすなわち、IPv6のためにないか、またはそのままですべてのIP Identification情報を送るとき(1に用意ができているRND/RND2によって示されるように)、減圧装置は圧縮されたベースヘッダーの中に送られたIP-IDビットを無視します。
Jonsson, et al. Standards Track [Page 23] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
イェンソン、他 規格は2007年2月にRFC4815修正と明確化をRFC3095に追跡します[23ページ]。
When RND=RND2=0, IP-ID is compressed, i.e., expressed as an SN offset and byte-swapped if NBO=0. This is the case also when 16 bits of IP-ID is sent in Extension 3.
RND=RND2=0、IP-IDがNBO=0であるなら圧縮されて、すなわち、SNオフセットとして言い表されてバイトと交換されているとき。 また、Extension3でIP-IDの16ビットを送るとき、これはそうです。
When RND=0 but no IP-ID bits are sent in the compressed header, the SN offset for IP-ID stays unchanged, meaning that Offset_m equals Offset_ref, as described in Section 4.5.5. This is further expressed in a slightly different way (with the same meaning) in Section 5.7, where it is said that "default-slope(IP-ID offset) = 0", meaning, if no bits are sent for IP-ID, its SN offset slope defaults to 0.
RND=0を送りますが、圧縮されたヘッダーでどんなIP-IDビットも送らないとき、IP-IDに相殺されたSNが変わりがないままです、Offset_mがOffset_審判と等しいことを意味して、セクション4.5.5で説明されるように。 これはさらにそれが言われているセクション5.7では、それが「SNがIP-IDにビットを全く送らないならスロープデフォルトを0まで相殺することを意味して、(IP-IDオフセット)=0インチにデフォルトで坂になる」わずかに異なった方法(同じ意味がある)で言い表されます。
8.3. Extension-3 in UOR-2* Packets
8.3. UOR-2*パケットの拡大-3
Some flags of the IP header in the extension (e.g., NBO or RND) may change the interpretation of fields in UOR-2* packets. In such cases, when a flag changes in Extension 3, a decompressor MUST re- parse the UOR-2* packet.
拡大(例えば、NBOかRND)におけるIPヘッダーのいくつかの旗がUOR-2*パケットの分野の解釈を変えるかもしれません。 旗がExtension3で変化するとき、そのような場合、減圧装置はUOR-2*パケットを再分析しなければなりません。
8.4. Multiple Occurrences of the M Bit
8.4. Mの複数の発生に噛み付きました。
The RTP header part of Extension 3, as defined by RFC 3095-Section 5.7.5, includes a one-bit field for the RTP Marker bit. This field is also present in all compressed base header formats except for UO- 1-ID; meaning, there may be two occurrences of the field within one single compressed header. In such cases, the two M fields must have the same value.
RFC3095セクションの5.7.5によって定義されるExtension3のRTPヘッダー部分はRTP Markerビット単位で1ビットの分野を含んでいます。 また、この分野もUOの1ID以外のすべての圧縮されたベースヘッダー形式で存在しています。 意味して、1個の独身の圧縮されたヘッダーの中に分野の2回の発生があるかもしれません。 分野には、そのような場合、そして、2M、同じ値がなければなりません。
FORMAL ADDITION TO RFC 3095:
RFC3095への正式な添加:
"When there are two occurrences of the M field in a compressed
header (both in the compressed base header and in the RTP part of
Extension 3), the compressor MUST set both these occurrences of
the M field to the same value.
「Mの2回の発生があるときには圧縮されたヘッダーで(圧縮されたベースヘッダーとExtension3のRTP部分の両方)をさばいてください、そして、コンプレッサーはMのこれらの発生が同じ値としてさばく両方を設定しなければなりません。」
At the decompressor, if the two M field values of such a packet
are not identical, the packet MUST be discarded."
「減圧装置では、そのようなパケットの2Mの分野値が同じでないなら、パケットを捨てなければなりません。」
8.5. Multiple SN options in one feedback packet
8.5. 1つのフィードバックパケットの複数のSNオプション
The length of the sequence number field in the original ESP [12] header is 32 bits. The format of the SN feedback option (RFC 3095- Section 5.7.6.6) allows for 8 additional SN bits to the 12 SN bits of the FEEDBACK-2 format (RFC 3095-Section 5.7.6.1). One single SN feedback option is thus not enough for the decompressor to send back all the 32 bits of the ESP sequence number in a feedback packet, unless it uses multiple SN options in one feedback packet.
オリジナルの超能力[12]ヘッダーの一連番号分野の長さは32ビットです。 SNフィードバックオプションの形式、(.6が)FEEDBACK-2形式の12SNビットに追加8SNビット考慮するRFC3095部5.7の.6、(RFC3095セクションの5.7.6、.1)。 その結果、減圧装置がフィードバックパケットの超能力一連番号のすべての32ビットを返送するように、1つのただ一つのSNフィードバックオプションは十分ではありません、1つのフィードバックパケットの複数のSNオプションを使用しない場合。
Jonsson, et al. Standards Track [Page 24] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
イェンソン、他 規格は2007年2月にRFC4815修正と明確化をRFC3095に追跡します[24ページ]。
RFC 3095-Section 5.7.6.1 declares that a FEEDBACK-2 packet can contain a variable number of feedback options, and the options can appear in any order.
.1がそのa FEEDBACK-2パケットであると宣言するRFC3095セクションの5.7.6は可変数のフィードバックオプションを含むことができます、そして、オプションは順不同に現れることができます。
When processing multiple SN options in one feedback packet, the SN would be given by concatenating the fields.
1つのフィードバックパケットで複数のSNオプションを処理するとき、分野を連結することによって、SNを与えるでしょう。
8.6. Multiple CRC Options in One Feedback Packet
8.6. 1つのフィードバックパケットの複数のCRCオプション
Although it is not useful to have more than one single CRC option in a feedback packet, having multiple CRC options is still allowed. If multiple CRC options are included, all such CRC options MUST be identical, as they will be calculated over the same header; the compressor MUST otherwise discard the feedback packet.
フィードバックパケットに1つ以上のただ一つのCRCオプションを持っているのが役に立ちませんが、複数のCRCオプションを持っているのはまだ許されています。 複数のCRCオプションが含まれているなら、そのようなすべてのCRCオプションが同じであるに違いありません、それらが同じヘッダーの上に計算されるように。 そうでなければ、コンプレッサーはフィードバックパケットを捨てなければなりません。
8.7. Responding to Lost Feedback Links
8.7. 無くなっているフィードバックリンクに応じます。
Although this is neither desirable or expected, it may happen that a link used to carry feedback between two associated instances becomes unavailable. If the compressor can be notified of such an event, the compressor SHOULD restart compression for each flow that is operating in R-mode. When restarting compression, the compressor SHOULD use a different CID for each flow being restarted; this is useful to avoid the possibility of misinterpreting the type of the compressed header for the packet type identifiers that are common to both U/O-mode and R-mode, when the flow is restarted in U-mode (see also Section 7.2).
これは、どちらも望ましいか予想されていますが、2つの関連例の間までフィードバックを運ぶのに使用されるリンクが入手できなくなるのは起こるかもしれません。 そのような出来事についてコンプレッサーに通知できるなら、コンプレッサーSHOULDはR-モードで作動している各流れのための圧縮を再開します。 圧縮を再開するとき、コンプレッサーSHOULDは再開される各流れに異なったCIDを使用します。 これはO U/モードとR-モードの両方に共通のパケットタイプ識別子のために圧縮されたヘッダーのタイプを誤解する可能性を避けるために役に立ちます、流れがU-モードで再開されるとき(また、セクション7.2を見てください)。
Generally, feedback links are not expected to disappear once present, but it should be noted that this might be the case for certain link technologies.
一般に、いったん存在しているとフィードバックリンクが見えなくならないと予想されますが、これが、あるリンク技術のためのそうであるかもしれないことに注意されるべきです。
8.8. UOR-2 in Profile 0x0002 (UDP) and Profile 0x0003 (ESP)
8.8. プロフィール0x0002(UDP)とプロフィール0x0003のUOR-2(超能力)
One single new format is defined for UOR-2 in profile 0x0002 and profile 0x0003, which replaces all three (UOR-2, UOR-2-ID, UOR-2-TS) formats from profile 0x0001. The same UOR-2 format is thus used independent of whether or not there are IP headers with a corresponding RND=1. This also applies to the IP profile [4] and the IP/UDP-Lite profile [5].
1つのただ一つの新しい書式がプロフィール0x0002とプロフィール0x0003のUOR-2のために定義されます。(UOR-2はプロフィール0x0001からすべての3つ(UOR-2、UOR2ID UOR-2-TS)の形式を取り替えます)。 IPヘッダーがあるかどうかの如何にかかわらず同じUOR-2形式は対応するRND=1と共にこのようにして使用されます。 また、これはIPプロフィール[4]とIP/UDP-Liteプロフィール[5]に適用されます。
8.9. Sequence Number LSB's in IP Extension Headers
8.9. IP拡張ヘッダーの一連番号LSBのもの
In RFC 3095-Section 5.8.5, formats are defined for compression of IP extension header fields. These include compressed sequence number fields, and these fields contain the "LSB of sequence number". These sequence numbers are not "LSB-encoded" as, e.g., the RTP sequence number, but are the LSB's of the uncompressed fields.
RFC3095セクションの5.8.5では、書式はIP拡大ヘッダーフィールドの圧縮のために定義されます。 これらは圧縮された一連番号分野を含んでいます、そして、これらの分野は「一連番号のLSB」を含んでいます。 これらの一連番号が「LSBによってコード化されていない」、例えば、RTP一連番号、LSBの解凍された分野のものはそうです。
Jonsson, et al. Standards Track [Page 25] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
イェンソン、他 規格は2007年2月にRFC4815修正と明確化をRFC3095に追跡します[25ページ]。
8.10. Expecting UOR-2 ACKs in O-Mode
8.10. O-モードでUOR-2 ACKsを予想します。
Usage of UOR-2 ACKs in O-mode, as discussed in RFC 3095-Section 5.4.1.1.2, is optional. A decompressor can also send ACKs for purposes other than to acknowledge the UOR-2, without having to continue sending ACKs for all UOR-2. Similarly, a compressor implementation can ignore UOR-2s ACKs for the purpose of adapting the optimistic approach strategies.
O-モードによるUOR-2 ACKsの使用法、RFC3095セクションの5.4.1で.1について議論して、.2は任意です。 また、減圧装置はUOR-2を承認するのを除いた目的のためにACKsを送ることができます、すべてのUOR-2のためにACKsを送り続ける必要はなくて。 同様に、コンプレッサー実現は楽観的なアプローチ戦略を適合させる目的のためにUOR-2ACKsを無視できます。
It is thus NOT RECOMMENDED to use the optional ACK mechanism in O- mode, either in compressor or in decompressor implementations.
その結果、それはOモード、コンプレッサーまたは減圧装置実現に任意のACKメカニズムを使用するNOT RECOMMENDEDです。
Using an incorrect expectation on UOR-2 ACKs as a basis for compressor behavior will significantly degrade the compression performance. This is because UOR-2 ACKs can be sent from a decompressor for other purposes than to acknowledge the UOR-2 packet, e.g., to send feedback such as clock resolution, or to initiate a mode transition. If an implementation does use the optional acknowledgment algorithm described in Section 5.4.1.1.2, it must make sure to set the k_3 and n_3 parameters to much larger values than 1 to ensure that the compressor performance is not degraded due to the problem described above.
コンプレッサーの振舞いの基礎としてUOR-2 ACKsで不正確な期待を使用すると、圧縮性能はかなり下げられるでしょう。 これは例えば時計解決などのフィードバックを送るか、またはモード変遷を開始するためにUOR-2パケットを承認すること以外の目的のための減圧装置からUOR-2 ACKsを送ることができるからです。 実現が任意の承認アルゴリズム説明されたコネセクション5.4.1.1.2を使用するなら、それは、コンプレッサー性能が上で説明された問題のため下げられないのを保証する1よりはるかに大きい値にk_3とn_3パラメタを設定するのを確実にしなければなりません。
8.11. Context Repairs, TS_STRIDE and TIME_STRIDE
8.11. tの文脈修理、_ストライド、およびタイム誌_は大股で歩きます。
The 7-bit CRC used to verify the outcome of the decompression attempt covers the original uncompressed header. The CRC verification thus excludes TS_STRIDE and TIME_STRIDE, as these fields are not part of the original uncompressed header.
CRCが減圧試みの結果について確かめるのに使用した7ビットはオリジナルの解凍されたヘッダーを覆っています。 その結果、CRC検証は、これらの分野がオリジナルの解凍されたヘッダーの一部でないので、TS_STRIDEとタイム誌_STRIDEを除きます。
The UOR-2 packet type can be used to update the value of the TS_STRIDE and/or the TIME_STRIDE, with the Extension 3. However, these fields are not used for decompression of the RTP TS field for this packet type and their respective value is thus not verified, either implicitly or explicitly.
TS_STRIDE、そして/または、タイム誌_STRIDEの値をアップデートするのにUOR-2パケットタイプを使用できます、Extension3と共に。 しかしながら、これらの分野はこのパケットタイプのためのRTP TS分野の減圧に使用されません、そして、彼らのそれぞれの値はこのようにしてそれとなくか明らかに確かめられません。
When the compressor receives a negative acknowledgement, it thus cannot determine whether the failure may be caused by an unsuccessful update to the TS_STRIDE and/or the TIME_STRIDE field(s), for which a previous header that last attempted to update their value had previously been acknowledged.
コンプレッサーが否定的承認を受けるとき、その結果、それは、失敗がTS_STRIDEへの失敗のアップデート、そして/または、タイム誌_STRIDE分野によって引き起こされるかもしれないかどうか決定できません。((以前に、分野において承認されました)最後に彼らの値をアップデートするのを試みた前のヘッダー)。
FORMAL ADDITION TO RFC 3095:
RFC3095への正式な添加:
"When the compressor receives a NACK and uses the UOR-2 header
type to repair the decompressor context, it SHOULD include fields
that update the value of both the TS_STRIDE and the TIME_STRIDE
whose value it has updated at least once since the establishment
「コンプレッサーがナックと用途を受けるとき、UOR-2ヘッダーは減圧装置文脈を修理するためにタイプして、それは設立以来それが少なくとも一度値をアップデートしたことがあるTS_STRIDEとタイム誌_STRIDEの両方の値をアップデートするSHOULDインクルード分野です」
Jonsson, et al. Standards Track [Page 26] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
イェンソン、他 規格は2007年2月にRFC4815修正と明確化をRFC3095に追跡します[26ページ]。
of that context, i.e., since the CID was first associated with
its current profile.
CIDが最初にその文脈すなわち、現在のプロフィールに関連していたので。
When the compressor receives a static-NACK, it MUST include in
the IR header fields for both the TS_STRIDE and the TIME_STRIDE
whose value it has updated at least once since the establishment
of that context, i.e., since the CID was first associated with
its current profile."
「コンプレッサーが静的なナックを受けるとき、TS_STRIDEとタイム誌_STRIDEの両方のためのIRヘッダーフィールドにその文脈の確立以来少なくとも一度だれの値をアップデートしたことがあるかを含まなければなりません、すなわち、CIDが最初に現在のプロフィールに関連していたので。」
9. ROHC Negotiation
9. ROHC交渉
RFC 3095-Section 4.1 states that the link layer must provide means to negotiate, e.g., the channel parameters listed in RFC 3095-Section 5.1.1. One of these parameters is the PROFILES parameter, which is a set of non-negative integers where each integer indicates a profile supported by the decompressor.
RFC3095セクションの4.1は、リンクレイヤが交渉する手段を提供しなければならないと述べます、例えばRFC3095セクションの5.1.1でリストアップされたチャンネルパラメタ。 これらのパラメタの1つはPROFILESパラメタです。(そのパラメタは各整数が減圧装置によって支えられたプロフィールを示す非負の整数のセットです)。
Each profile is identified by a 16-bit value, where the 8 LSB bits indicate the actual profile, and the 8 MSB bits indicate the variant of that profile (see RFC 3095-Section 8). In the ROHC headers sent over the link, the profile used is identified only with the 8 LSB bits, which means that the compressor and decompressor must have agreed on which variant to use for each profile.
各プロフィールは16ビットの値によって特定されます。そこで、8LSBビットは実際のプロフィールを示して、8MSBビットはそのプロフィールの異形を示します(RFCの3095セクションの8を見てください)。 リンクの上に送られたROHCヘッダーでは、使用されるプロフィールは単に8LSBビットで特定されます。(ビットは、コンプレッサーと減圧装置が、各プロフィールにどの異形を使用したらよいかに同意したに違いないことを意味します)。
The negotiation protocol must thus be able to communicate to the compressor the set of profiles supported by the decompressor. When multiple variants of the same profile are available, the negotiation protocol must provide the means for the decompressor to know which variant will be used by the compressor. This basically means that the PROFILES set after negotiation MUST NOT include more than one variant of a profile.
その結果、交渉プロトコルは減圧装置によって支えられたプロフィールのセットをコンプレッサーに伝えることができなければなりません。 同じプロフィールの複数の異形が利用可能であるときに、交渉プロトコルは、どの異形がコンプレッサーによって使用されるかを知るために手段を減圧装置に提供しなければなりません。 これは、交渉がプロフィールの1つ以上の異形を含んではいけなかった後にPROFILESがセットしたことを基本的に意味します。
10. PROFILES Sub-option in ROHC-over-PPP
10. ROHC過剰pppにおけるサブオプションのプロフィール
The logical union of sub-options for IPCP and IPV6CP negotiations, as specified by ROHC over PPP [2], cannot be used for the PROFILES suboption, as the whole union would then have to be considered within each of the two IPCP negotiations to avoid getting an ambiguous profile set. An implementation of RFC 3241 MUST therefore ensure that the same profile set is negotiated for both IPv4 and IPv6 (IPCP/IPV6CP).
PROFILES suboptionにPPP[2]の上でROHCによって指定されるIPCPのためのサブオプションとIPV6CP交渉の論理的な組合は使用できません、次に、それぞれの2つのIPCP交渉の中で全体の組合が、あいまいなプロフィールセットを手に入れるのを避けると考えられなければならないだろうというとき。 したがって、RFC3241の実現は、同じプロフィールセットがIPv4とIPv6の両方(IPCP/IPV6CP)のために交渉されるのを確実にしなければなりません。
11. Constant IP-ID Encoding in IP-only and UPD-Lite Profiles
11. IPだけとUPD-Liteでプロフィールをコード化する一定のIP-ID
In the ROHC IP-only profile, Section 3.3 of RFC 3843 [4], a mechanism for encoding of a constant Identification value in IPv4 (constant IP-ID) is defined. This mechanism is also used by the ROHC UDP-Lite profiles, RFC 4019 [5].
ROHC IPだけプロフィール、RFC3843[4]のセクション3.3、定義されるIdentificationがIPv4(一定のIP-ID)で評価する定数のコード化のためのメカニズムで。 また、このメカニズムはROHC UDP-Liteプロフィール、RFC4019[5]によって使用されます。
Jonsson, et al. Standards Track [Page 27] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
イェンソン、他 規格は2007年2月にRFC4815修正と明確化をRFC3095に追跡します[27ページ]。
The "Constant IP-ID" mechanism applies to both the inner and outer IP header, when present, meaning that there will be both a SID and a SID2 context value.
「一定のIP-ID」メカニズムは内側の、そして、外側のIPヘッダーに適用されます、存在しているとき、SIDとSID2文脈価値の両方があることを意味して。
12. Security Considerations
12. セキュリティ問題
This document provides a number of corrections and clarifications to [1], but it does not make any changes with regard to the security aspects of the protocol. As a consequence, the security considerations of [1] apply without additions.
このドキュメントは多くの修正と明確化を[1]に提供しますが、それはプロトコルのセキュリティ局面に関してどんな変更も行いません。 結果として、[1]のセキュリティ問題は追加なしで適用されます。
13. Acknowledgments
13. 承認
The authors would like to thank Vicknesan Ayadurai, Carsten Bormann, Mikael Degermark, Zhigang Liu, Abigail Surtees, Mark West, Tommy Lundemo, Alan Kennington, Remi Pelland, Lajos Zaccomer, Endre Szalai, Mark Kalmanczhelyi, and Arpad Szakacs for their contributions and comments. Thanks also to the committed document reviewers, Carl Knutsson and Biplab Sarkar, who reviewed the document during working group last-call.
作者は彼らの貢献とコメントについてVicknesan Ayadurai、カルステン・ボルマン、マイケル・デーゲルマルク、Zhigangリュウ、アビゲール・サーティーズ、マーク西洋、トミーLundemo、アラン・ケニントン、レミPelland、Lajos Zaccomer、エンドレSzalai、マークKalmanczhelyi、およびアルパドSzakacsに感謝したがっています。 また、遂行されたドキュメント評論家、カールKnutsson、およびBiplabサルカールをありがとうございます。(サルカールは、ワーキンググループの最後の呼び出しの間、ドキュメントを再検討しました)。
14. References
14. 参照
14.1. Normative References
14.1. 引用規格
[1] 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.
[1] ボルマン、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日
[2] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC
3241, April 2002.
[2] ボルマン、2002年4月、C.、「pppの上の体力を要しているヘッダー圧縮(ROHC)」RFC3241。
[3] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July
1994.
[3] シンプソン、W.、「HDLCのような縁どりにおけるppp」、STD51、RFC1662、1994年7月。
[4] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
(ROHC): A Compression Profile for IP", RFC 3843, June 2004.
[4] イェンソン、L-E.、およびG.ペレティア、「体力を要しているヘッダー圧縮(ROHC):」 「IPのための圧縮プロフィール」、RFC3843、2004年6月。
[5] Pelletier, G., "RObust Header Compression (ROHC): Profiles for
User Datagram Protocol (UDP) Lite", RFC 4019, April 2005.
[5] ペレティア、G.、「体力を要しているヘッダー圧縮(ROHC):」 「ユーザー・データグラム・プロトコル(UDP)Liteのためのプロフィール」、RFC4019、2005年4月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Jonsson, et al. Standards Track [Page 28] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
イェンソン、他 規格は2007年2月にRFC4815修正と明確化をRFC3095に追跡します[28ページ]。
14.2. Informative References
14.2. 有益な参照
[7] Jonsson, L-E., Pelletier, G., and K. Sandlund, "RObust Header
Compression (ROHC): A Link-Layer Assisted Profile for
IP/UDP/RTP", RFC 4362, January 2006.
[7] イェンソン、L-E.、ペレティア、G.、およびK.Sandlund、「体力を要しているヘッダー圧縮(ROHC):」 「リンクレイヤはIP/UDP/RTPのためにプロフィールを補助した」RFC4362、2006年1月。
[8] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[8] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[9] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[9] デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[10] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[10] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[11] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[11]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[12] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005.
[12] ケント、S.、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC4303、2005年12月。
[13] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its
Use With IPsec", RFC 2410, November 1998.
[13] グレン、R.、S.ケント、および「ヌル暗号化アルゴリズムとIPsecとのその使用」、RFC2410、11月1998日
[14] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[14] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
[15] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
[15] パーキンス、C.、「IPの中の最小量のカプセル化」、RFC2004、1996年10月。
[16] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
2000年3月の[16] ファリナッチとD.と李とT.とハンクスとS.とマイヤー、D.とP.Traina、「一般ルーティングのカプセル化(GRE)」RFC2784。
[17] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC
2890, September 2000.
[17]Dommety、G.、「GREへのキーと一連番号拡大」、RFC2890、2000年9月。
Jonsson, et al. Standards Track [Page 29] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
イェンソン、他 規格は2007年2月にRFC4815修正と明確化をRFC3095に追跡します[29ページ]。
Appendix A. Sample CRC Algorithm
付録A.サンプルCRCアルゴリズム
#!/usr/bin/perl -w
use strict;
#=================================
#
# ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02
#
# This little demo shows the four types of CRCs in use in RFC 3095,
# the specification for robust header compression. Type your data in
# hexadecimal form and then press Control+D.
#
#---------------------------------
#
# utility
#
sub dump_bytes($) {
my $x = shift;
my $i;
for ($i = 0; $i < length($x); ) {
printf("%02x ", ord(substr($x, $i, 1)));
printf("\n") if (++$i % 16 == 0);
}
printf("\n") if ($i % 16 != 0);
}
#/usr/bin/perl-w使用厳しい。 #================================= # # ROHC CRCデモ--カルステンボルマンの cabo@tzi.org 2001年8月2日##ThisデモはほとんどRFC3095、#で使用中のCRCsの4つのタイプに体力を要しているヘッダー圧縮のための仕様を示していません。 #16進フォームでデータをタイプしてください、そして、次に、Control+Dを押してください。 # #--------------------------------- # # ユーティリティ#潜水艦ダンプ_バイト($)シフト..長さ
#---------------------------------
#
# The CRC calculation algorithm.
#
sub do_crc($$$) {
my $nbits = shift;
my $poly = shift;
my $string = shift;
#--------------------------------- # # CRC計算アルゴリズム。 # 潜水艦が_crcに($$$)をする、私の$nbitsはシフト; 私の$のポリー=のシフト; 私の$ストリング=シフトと等しいです。
my $crc = ($nbits == 32 ? 0xffffffff : (1 << $nbits) - 1);
for (my $i = 0; $i < length($string); ++$i) {
my $byte = ord(substr($string, $i, 1));
for( my $b = 0; $b < 8; $b++ ) {
if (($crc & 1) ^ ($byte & 1)) {
$crc >>= 1;
$crc ^= $poly;
} else {
$crc >>= 1;
}
$byte >>= 1;
}
}
私の$crc=(nbits=32ドル?0xffffffff: (1<<ドルのnbits)--1)。 (私の$i=0; $i<の長さ($ストリング); + + $i)で(私の$b=0; b<8ドル; $b++)の私の$バイト=ord(($ストリング、$i、1)をsubstrする)、((crcと1ドル)の^(バイトと1ドル))である、$crc^が$とcrc>>=1ドル、等しい、ポリー、;、ほか、crc>>=1ドル; バイト>>=1ドル。
Jonsson, et al. Standards Track [Page 30] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
イェンソン、他 規格は2007年2月にRFC4815修正と明確化をRFC3095に追跡します[30ページ]。
printf "%2d bits, ", $nbits;
printf "CRC: %02x\n", $crc;
}
"printf"%2d、ビット、」、$nbits。 printf、「CRC:」 「%02x\n」、$crc。 }
#--------------------------------- # # Test harness # $/ = undef; $_ = <>; # read until EOF my $string = ""; # extract all that looks hex: s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg; dump_bytes($string);
#--------------------------------- # # 馬具#$/=undefをテストしてください。 $_ = <>; # EOFまで私の$ストリング=を読んでください、「「;」 # そのすべての面相十六進法を抽出してください: s/[0-9 fA F][0-9 fA F)/$ストリング= chr(魔法をかけます(1ドル))、「「/eg」 _バイト($ストリング)をどさっと落としてください。
#--------------------------------- # # 32-bit segmentation CRC # Note that the text implies that this is complemented like for PPP # (this differs from 8-, 7-, and 3-bit CRCs) # # C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 + # x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32 # do_crc(32, 0xedb88320, $string);
#--------------------------------- # # 32-bit segmentation CRC # Note that the text implies that this is complemented like for PPP # (this differs from 8-, 7-, and 3-bit CRCs) # # C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 + # x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32 # do_crc(32, 0xedb88320, $string);
#--------------------------------- # # 8-bit IR/IR-DYN CRC # # C(x) = x^0 + x^1 + x^2 + x^8 # do_crc(8, 0xe0, $string);
#--------------------------------- # # x^0+x^1+x^2+x^8 8ビットのIR IR/DYN CRC##C(x)=#、は_crc(8、0xe0、$ストリング)をします。
#--------------------------------- # # 7-bit FO/SO CRC # # C(x) = x^0 + x^1 + x^2 + x^3 + x^6 + x^7 # do_crc(7, 0x79, $string);
#--------------------------------- # # 7ビットのFO/SO CRC##^2+x^3+x^^7C(x)=x^0+x^1+x6+x#、は_crc(7、0×79、$ストリング)をします。
#--------------------------------- # # 3-bit FO/SO CRC # # C(x) = x^0 + x^1 + x^3 # do_crc(3, 0x6, $string);
#--------------------------------- # # x^0+x^1+x^3 3ビットのFO/SO CRC##C(x)=#、は_crc(3、0×6、$ストリング)をします。
Jonsson, et al. Standards Track [Page 31] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
イェンソン、他 規格は2007年2月にRFC4815修正と明確化をRFC3095に追跡します[31ページ]。
Authors' Addresses
作者のアドレス
Lars-Erik Jonsson Optand 737 SE-831 92 Ostersund, Sweden Phone: +46 70 365 20 58 EMail: lars-erik@lejonsson.com
ラース-エリックイェンソンOptand737SE-831 92エースタズンド(スウェーデン)は以下に電話をします。 +46 70 365 20 58はメールされます: lars-erik@lejonsson.com
Kristofer Sandlund Ericsson AB Box 920 SE-971 28 Lulea, Sweden Phone: +46 8 404 41 58 EMail: kristofer.sandlund@ericsson.com
クリストファSandlundエリクソンAB箱920のSE-971 28ルーレオ(スウェーデン)は以下に電話をします。 +46 8 404 41 58はメールされます: kristofer.sandlund@ericsson.com
Ghyslain Pelletier Ericsson AB Box 920 SE-971 28 Lulea, Sweden Phone: +46 8 404 29 43 EMail: ghyslain.pelletier@ericsson.com
GhyslainペレティアエリクソンAB箱920のSE-971 28ルーレオ(スウェーデン)は以下に電話をします。 +46 8 404 29 43はメールされます: ghyslain.pelletier@ericsson.com
Peter Kremer Conformance and Software Test Laboratory Ericsson Hungary H-1300 Bp. 3., P.O. Box 107, HUNGARY Phone: +36 1 437 7033 EMail: peter.kremer@ericsson.com
ピータークレーメルConformanceとソフトウェアは研究所エリクソンハンガリーH-1300 Bpをテストします。 3. 私書箱107、ハンガリーは以下に電話をします。 +36 1 437 7033はメールされます: peter.kremer@ericsson.com
Jonsson, et al. Standards Track [Page 32] RFC 4815 Corrections and Clarifications to RFC 3095 February 2007
イェンソン、他 規格は2007年2月にRFC4815修正と明確化をRFC3095に追跡します[32ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Jonsson, et al. Standards Track [Page 33]
イェンソン、他 標準化過程[33ページ]
一覧
スポンサーリンク
