RFC4019 日本語訳
4019 RObust Header Compression (ROHC): Profiles for User DatagramProtocol (UDP) Lite. G. Pelletier. April 2005. (Format: TXT=46896 bytes) (Updated by RFC4815) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Pelletier Request for Comments: 4019 Ericsson AB Category: Standards Track April 2005
コメントを求めるワーキンググループG.ペレティア要求をネットワークでつないでください: 4019年のエリクソンABカテゴリ: 標準化過程2005年4月
RObust Header Compression (ROHC):
Profiles for User Datagram Protocol (UDP) Lite
体力を要しているヘッダー圧縮(ROHC): ユーザー・データグラム・プロトコル(UDP)Liteのためのプロフィール
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 (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document defines Robust Header Compression (ROHC) profiles for compression of Real-Time Transport Protocol, User Datagram Protocol- Lite, and Internet Protocol (RTP/UDP-Lite/IP) packets and UDP- Lite/IP. These profiles are defined based on their differences with the profiles for UDP as specified in RFC 3095.
このドキュメントはレアル-時間Transportプロトコル、UserデータグラムプロトコルLite、インターネットプロトコル(RTP/UDP-Lite/IP)パケット、およびUDP- Lite/IPの圧縮のためのRobust Header Compression(ROHC)プロフィールを定義します。 これらのプロフィールはRFC3095の指定されるとしてのUDPのためのプロフィールがあるそれらの違いに基づいて定義されます。
Table of Contents
目次
1. Introduction.................................................. 2
2. Terminology................................................... 3
3. Background.................................................... 3
3.1. Overview of the UDP-Lite Protocol....................... 3
3.2. Expected Behaviours of UDP-Lite Flows................... 5
3.2.1. Per-Packet Behavior............................. 5
3.2.2. Inter-Packet Behavior........................... 5
3.2.3. Per-Flow Behavior............................... 5
3.3. Header Field Classification............................. 5
4. Rationale behind the Design of ROHC Profiles for UDP-Lite..... 6
4.1. Design Motivations...................................... 6
4.2. ROHC Considerations..................................... 6
5. ROHC Profiles for UDP-Lite.................................... 6
5.1. Context Parameters...................................... 7
5.2. Initialization.......................................... 8
5.2.1. Initialization of the UDP-Lite Header [1]....... 8
5.2.2. Compressor and Decompressor Logic............... 9
1. 序論… 2 2. 用語… 3 3. バックグラウンド… 3 3.1. UDP-Liteプロトコルの概観… 3 3.2. UDP-Liteの予想されたふるまいは流れます… 5 3.2.1. 1パケットあたりの振舞い… 5 3.2.2. 相互パケットの振舞い… 5 3.2.3. 流動作用単位で… 5 3.3. ヘッダーフィールド分類… 5 4. UDP-LiteのためのROHCプロフィールのデザインの後ろの原理… 6 4.1. 動機を設計してください… 6 4.2. ROHC問題… 6 5. UDP-LiteのためのROHCプロフィール… 6 5.1. 文脈パラメタ… 7 5.2. 初期設定… 8 5.2.1. UDP-Liteヘッダー[1]の初期設定… 8 5.2.2. コンプレッサーと減圧装置論理… 9
Pelletier Standards Track [Page 1] RFC 4019 ROHC: Profiles for UDP-Lite April 2005
ペレティアStandardsはRFC4019ROHCを追跡します[1ページ]: UDP-Liteのために、2005年4月の輪郭を描きます。
5.3. Packet Formats.......................................... 9
5.3.1. General Packet Format........................... 9
5.3.2. Packet Type CCE: CCE(), CCE(ON), and CCE(OFF)... 10
5.3.2.1. Properties of CCE():.................. 11
5.3.2.2. Properties of CCE(ON):................ 11
5.3.2.3. Properties of CCE(OFF):............... 12
5.4. Compressor Logic........................................ 12
5.5. Decompressor Logic...................................... 12
5.6. Additional Mode Transition Logic........................ 13
5.7. The CONTEXT_MEMORY Feedback Option...................... 13
5.8. Constant IP-ID.......................................... 13
6. Security Considerations....................................... 14
7. IANA Considerations........................................... 14
8. Acknowledgments............................................... 15
9. References.................................................... 15
9.1. Normative References.................................... 15
9.2. Informative References.................................. 15
Appendix A. Detailed Classification of Header Fields............. 17
Appendix B. Detailed Format of the CCE Packet Type............... 20
Author's Address.................................................. 22
Full Copyright Statement.......................................... 23
5.3. パケット形式… 9 5.3.1. 一般パケット・フォーマット… 9 5.3.2. パケットタイプCCE: CCE()、CCE(ON)、およびCCE(OFF)… 10 5.3.2.1. CCE()の特性:、… 11 5.3.2.2. CCE(ON)の特性:、… 11 5.3.2.3. CCE(OFF)の特性:、… 12 5.4. コンプレッサー論理… 12 5.5. 減圧装置論理… 12 5.6. 追加モード変遷論理… 13 5.7. 文脈_メモリフィードバックオプション… 13 5.8. 一定のIP-ID… 13 6. セキュリティ問題… 14 7. IANA問題… 14 8. 承認… 15 9. 参照… 15 9.1. 標準の参照… 15 9.2. 有益な参照… 15 付録A.はヘッダーフィールドの分類を詳しく述べました… 17 付録B.はCCEパケットタイプの書式を詳しく述べました… 20作者のアドレス… 22 完全な著作権宣言文… 23
1. Introduction
1. 序論
The ROHC WG has developed a header compression framework on top of which various profiles can be defined for different protocol sets or compression strategies. Due to the demands of the cellular industry for an efficient way to transport voice over IP over wireless, ROHC [2] has mainly focused on compression of IP/UDP/RTP headers, which are generous in size, especially compared to the payloads often carried by packets with these headers.
ROHC WGは上異なったプロトコルセットか圧縮戦略のために様々なプロフィールを定義できるヘッダー圧縮枠組みを開発しました。 効率的な道のためのセル産業が無線電信の上でIPの上で声を輸送するという要求のため、ROHC[2]はサイズで豊富なIP/UDP/RTPヘッダーの圧縮に主に焦点を合わせました、これらのヘッダーと共にパケットによってしばしば運ばれたペイロードと特に比べて。
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 high extent, even when residual bit errors are present in compressed headers delivered to the decompressor.
ROHC RTPは非常に効率的で、強健で、できる圧縮技術になりました、ヘッダーを1つの八重奏だけの総サイズまで圧縮できます。 また、透明は非常に高い程度まで保証されます、残りの噛み付いている誤りが減圧装置に届けられた圧縮されたヘッダーに存在してさえいるとき。
UDP-Lite [4] is a transport protocol similar to the UDP protocol [7]. UDP-Lite is useful for applications designed with the capability to tolerate errors in the payload, for which receiving damaged data is better than dealing with the loss of entire packets. This may be particularly suitable when packets are transported over link technologies in which data can be partially damaged, such as wireless links.
UDP-Lite[4]はUDPプロトコル[7]と同様のトランスポート・プロトコルです。 UDP-Liteは破損しているデータを受け取るのが全体のパケットの損失に対処するより良いペイロードにおける誤りを許容する能力で設計されたアプリケーションの役に立ちます。 パケットがデータが部分的に破損している場合があるリンク技術の上で輸送されるとき、これは特に適当であるかもしれません、無線のリンクなどのように。
Pelletier Standards Track [Page 2] RFC 4019 ROHC: Profiles for UDP-Lite April 2005
ペレティアStandardsはRFC4019ROHCを追跡します[2ページ]: UDP-Liteのために、2005年4月の輪郭を描きます。
Although these transport protocols are very similar, ROHC profiles must be defined separately for robust compression of UDP-Lite headers because UDP-Lite does not share the same protocol identifier with UDP. Also, the UDP-Lite Checksum Coverage field does not share the semantics of the corresponding UDP Length field, and as a consequence it cannot always be inferred anymore.
これらのトランスポート・プロトコルは非常に同様ですが、UDP-Liteが同じプロトコル識別子をUDPと共有しないので、UDP-Liteヘッダーの体力を要している圧縮のために別々にROHCプロフィールを定義しなければなりません。 また、UDP-Lite Checksum Coverage分野は対応するUDP Length分野の意味論を共有しません、そして、結果として、それ以上いつもそれは推論できるというわけではありません。
This document defines two ROHC profiles for efficient compression of UDP-Lite headers. The objective of this document is to provide simple modifications to the corresponding ROHC profiles for UDP, specified in RFC 3095 [2]. In addition, the ROHC profiles for UDP- Lite support some of the mechanisms defined in the profile for compression of IP headers [3] (ROHC IP-Only). This specification includes support for compression of multiple IP headers and for compressing IP-ID fields with constant behavior, as well as improved mode transition logic and a feedback option for decompressors with limited memory resources.
このドキュメントはUDP-Liteヘッダーの効率的な圧縮のための2個のROHCプロフィールを定義します。 このドキュメントの目的はRFC3095[2]で指定されたUDPのための対応するROHCプロフィールへの簡単な変更を提供することです。 さらに、UDP- LiteのためのROHCプロフィールはIPヘッダー[3](ROHC IP専用)の圧縮のためのプロフィールで定義されたメカニズムのいくつかを支持します。 この仕様は複数のIPヘッダーの圧縮と一定の振舞いでIP-ID分野を圧縮するサポートを含んでいます、改良されたモード変遷論理と限られたメモリリソースがある減圧装置のためのフィードバックオプションと同様に。
2. Terminology
2. 用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD, "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1].
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、「「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように解釈されることであるべきですか?」
ROHC RTP : RTP/UDP/IP profile 0x0001 defined in RFC 3095 [2]. ROHC UDP : UDP/IP profile 0x0002 defined in RFC 3095 [2]. ROHC UDP-Lite : UDP-Lite/IP profile defined in this document. ROHC RTP/UDP-Lite: RTP/UDP-Lite/IP profile defined in this document.
ROHC RTP: RTP/UDP/IPプロフィール0x0001はRFCで3095[2]を定義しました。 ROHC UDP: UDP/IPプロフィール0x0002はRFCで3095[2]を定義しました。 ROHC UDP-Lite: 本書では定義されたUDP-Lite/IPプロフィール。 ROHC RTP/UDP-Lite: 本書では定義されたRTP/UDP-Lite/IPプロフィール。
3. Background
3. バックグラウンド
3.1. Overview of the UDP-Lite Protocol
3.1. UDP-Liteプロトコルの概観
UDP-Lite is a transport protocol defined as an independent variant of the UDP transport protocol. UDP-Lite is very similar to UDP, and it allows applications that can tolerate errors in the payload to use a checksum with an optional partial coverage. This is particularly useful with IPv6 [6], in which the use of the transport-layer checksum is mandatory.
UDP-LiteはUDPトランスポート・プロトコルの独立している異形と定義されたトランスポート・プロトコルです。 UDP-LiteはUDPと非常に同様です、そして、それはペイロードにおける誤りを許容できるアプリケーションが任意の部分的な適用範囲があるチェックサムを使用するのを許容します。 これはIPv6[6]によって特に役に立ちます。そこでは、トランスポート層チェックサムの使用が義務的です。
UDP-Lite replaces the Length field of the UDP header with a Checksum Coverage field. This field indicates the number of octets covered by the 16-bit checksum, which is applied on a per-packet basis. The coverage area always includes the UDP-Lite header and may cover the entire packet, in which case UDP-Lite becomes semantically identical to UDP. UDP-Lite and UDP do not share the same protocol identifier.
UDP-LiteはUDPヘッダーのLength野原をChecksum Coverage分野に取り替えます。 この分野は1パケットあたり1個のベースで適用される16ビットのチェックサムでカバーされた八重奏の数を示します。 適用範囲の地域は、いつもUDP-Liteヘッダーを含んで、全体のパケットを含むかもしれません、その場合、UDP-LiteはUDPと意味的に同じになります。 UDP-LiteとUDPは同じプロトコル識別子を共有しません。
Pelletier Standards Track [Page 3] RFC 4019 ROHC: Profiles for UDP-Lite April 2005
ペレティアStandardsはRFC4019ROHCを追跡します[3ページ]: UDP-Liteのために、2005年4月の輪郭を描きます。
The UDP-Lite header format:
UDP-Liteヘッダー形式:
0 15 16 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| Checksum | |
| Coverage | Checksum |
+--------+--------+--------+--------+
| |
: Payload :
| |
+-----------------------------------+
0 15 16 31 +--------+--------+--------+--------+ | ソース| 目的地| | ポート| ポート| +--------+--------+--------+--------+ | チェックサム| | | 適用範囲| チェックサム| +--------+--------+--------+--------+ | | : 有効搭載量: | | +-----------------------------------+
Like the UDP checksum, the UDP-Lite checksum is an end-to-end mechanism against erroneous delivery of error sensitive data. This checksum is mandatory with IPv6 [5] for both protocols. However, unlike its UDP counterpart, the UDP-Lite checksum may not be transmitted as all zeroes and cannot be disabled for IPv4 [5]. For UDP, if the checksum is disabled (IPv4 only), the Checksum field maintains a constant value and is normally not sent by the header compression scheme. If the UDP checksum is enabled (mandatory for IPv6), such an unpredictable field cannot be compressed and is sent uncompressed. The UDP Length field, however, is always redundant and can be provided by the IP module. Header compression schemes do not normally transmit any bits of information for this field, as its value can be inferred from the link layer.
UDPチェックサムのように、UDP-Liteチェックサムは誤り極秘データの誤った配送に対する終わりから終わりへのメカニズムです。 このチェックサムはIPv6[5]によって両方のプロトコルに義務的です。 しかしながら、UDP対応者と異なって、UDP-Liteチェックサムをすべてのゼロとして伝えないかもしれなくて、IPv4[5]のために無効にすることができません。 UDPに関しては、チェックサムは障害があるなら(IPv4専用)、Checksum野原は、恒常価値を維持して、通常、ヘッダー圧縮技術によって送られません。 UDPチェックサムを可能にするなら(IPv6に義務的な)、そのような予測できない野原を圧縮できないで、解凍されていた状態で送ります。 UDP Length野原をしかしながら、いつも余分であり、IPモジュールで供給できます。 通常、ヘッダー圧縮技術はこの分野のためのどんなビットの情報も伝えません、リンクレイヤから値を推論できるとき。
For UDP-Lite, the checksum also has unpredictable values, and this field must always be included as-is in the compressed header for both IPv4 and IPv6. Furthermore, as the UDP Length field is redefined as the Checksum Coverage field by UDP-Lite, this leads to different properties for this field from a header-compression perspective.
また、UDP-Liteに関しては、チェックサムには、予測できない値があります、そして、IPv4とIPv6の両方のための圧縮されたヘッダーにいつもそのままでこの分野を含まなければなりません。 その上、UDP Length分野がUDP-LiteによってChecksum Coverage分野と再定義されるとき、これはこの分野へのヘッダー圧縮見解と異なった特性に通じます。
The following summarizes the relationship between UDP and UDP-Lite:
以下はUDPとUDP-Liteとの関係をまとめます:
- UDP-Lite and UDP have different protocol identifiers.
- The UDP-Lite checksum cannot be disabled for IPv4.
- UDP-Lite redefines the UDP Length field as the Checksum Coverage
field, with different semantics.
- UDP-Lite is semantically equivalent to UDP when the Checksum
Coverage field indicates the total length of the packet.
- UDP-LiteとUDPには、異なったプロトコル識別子があります。 - IPv4のためにUDP-Liteチェックサムを無効にすることができません。 - UDP-Liteは、異なった意味論でUDP Length分野をChecksum Coverage分野と再定義します。 - Checksum Coverage分野がパケットの全長を示すとき、UDP-LiteはUDPに意味的に同等です。
The next section provides a more detailed discussion of the behavior of the Checksum Coverage field of UDP-Lite in relation to header compression.
次のセクションはヘッダー圧縮と関連してUDP-LiteのChecksum Coverage分野の振舞いの、より詳細な議論を提供します。
Pelletier Standards Track [Page 4] RFC 4019 ROHC: Profiles for UDP-Lite April 2005
ペレティアStandardsはRFC4019ROHCを追跡します[4ページ]: UDP-Liteのために、2005年4月の輪郭を描きます。
3.2. Expected Behaviours of UDP-Lite Flows
3.2. UDP-Liteの予想されたふるまいは流れます。
3.2.1. Per-Packet Behavior
3.2.1. 1パケットあたりの振舞い
As mentioned in the previous section, the checksum coverage value is applied independently of other packets that may belong to the same flow. Specifically, the value of the checksum coverage may indicate that the UDP-Lite packet is either entirely covered by the checksum or covered up to some boundary less than the packet size but including the UDP-Lite header.
前項で言及されるように、チェックサム適用範囲価値は同じ流れに属すかもしれない他のパケットの如何にかかわらず適用されます。 明確に、チェックサム適用範囲の値は、UDP-Liteパケットがチェックサムで完全に覆われるか、パケットサイズより少ない何らかの境界まで覆われますが、またはUDP-Liteヘッダーを含んでいるのを示すかもしれません。
3.2.2. Inter-Packet Behavior
3.2.2. 相互パケットの振舞い
In relation to each other, UDP-Lite packets may exhibit one of three possible change patterns, where within a sequence of packets the value of the Checksum Coverage field is
互いと関連して、UDP-Liteパケットは3つの可能な変化パターンの1つを示すかもしれません。そこでは、Checksum Coverage分野の値がパケットの系列の中では、そうです。
1. changing, while covering the entire packet; 2. unchanging, covering up to a fixed boundary within the packet; or 3. changing, but it does not follow any specific pattern.
1. 全体のパケットを覆っている間、変化します。 2. 変らなくて、aへ隠すのはパケットの中で境界を修理しました。 3 または、しかし、変化、それはどんな特定のパターンにも従いません。
The first pattern above corresponds to the semantics of UDP, when the UDP checksum is enabled. For this case, the checksum coverage field varies according to the packet length and may be inferred from the IP header, as is the UDP Length field value.
UDPチェックサムが可能にされるとき、上の最初のパターンはUDPの意味論に一致しています。 このような場合、チェックサム適用範囲分野は、パケット長に従って異なって、IPヘッダーから推論されるかもしれません、UDP Length分野価値のように。
The second pattern corresponds to the case where the coverage is the same from one packet to another within a particular sequence. For this case, the Checksum Coverage field may be a static value defined in the context, and it does not have to be sent in the compressed header. For the third case, no useful change pattern can be identified from packet to packet for the value of the checksum coverage field, and it must be included in the compressed header.
2番目のパターンは適用範囲が特定の系列の中で1つのパケットから別のパケットまで同じであるケースに一致しています。 このような場合、Checksum Coverage分野は文脈で定義された静的な値であるかもしれません、そして、圧縮されたヘッダーでそれを送る必要はありません。 3番目のケースにおいて、チェックサム適用範囲分野の値のためにどんな役に立つ変化パターンもパケットからパケットまで特定できません、そして、圧縮されたヘッダーにそれを含まなければなりません。
3.2.3. Per-Flow behavior
3.2.3. 流動作用
It can be expected that any one of the above change patterns for sequences of packets may be predominant at any time during the lifetime of the UDP-Lite flow. A flow that predominantly follows the first two change patterns described above may provide opportunities for compressing the Checksum Coverage field for most of the packets.
パケットの系列のための上の変化パターンのどれかがいつでもUDP-Lite流動の生涯支配的であるかもしれないと予想できます。 上で説明された最初の2つの変化パターンに支配的に続いて起こる流れはパケットの大部分のためにChecksum Coverage分野を圧縮するのに機会を与えるかもしれません。
3.3. Header Field Classification
3.3. ヘッダーフィールド分類
In relation to the header field classification of RFC 3095 [2], the first two patterns represent the case where the value of the Checksum Coverage field behavior is fixed and may be either INFERRED (pattern
最初の2つのパターンがRFC3095[2]のヘッダーフィールド分類と関連したChecksum Coverage分野の振舞いの値が固定されているケースを表して、INFERREDであるかもしれない、(パターン
Pelletier Standards Track [Page 5] RFC 4019 ROHC: Profiles for UDP-Lite April 2005
ペレティアStandardsはRFC4019ROHCを追跡します[5ページ]: UDP-Liteのために、2005年4月の輪郭を描きます。
1) or STATIC (pattern 2). Pattern 3 is for the case where the value varies unpredictably, the field is CHANGING, and the value must be sent along with every packet.
1) または、静的です(パターン2)。 パターン3はケースのために値が予想外に異なるところにあります、そして、分野はCHANGINGです、そして、あらゆるパケットと共に値を送らなければなりません。
Additional information regarding the analysis of the behavior of the UDP-Lite fields may be found in Appendix A.
UDP-Lite分野の振舞いの分析に関する追加情報はAppendix Aで見つけられるかもしれません。
4. Rationale behind the Design of ROHC Profiles for UDP-Lite
4. UDP-LiteのためのROHCプロフィールのデザインの後ろの原理
4.1. Design Motivations
4.1. デザイン動機
Simplicity is a strong motivation for the design of the UDP-Lite header compression profiles. The profiles defined for UDP-Lite should entail only a few simple modifications to the corresponding profiles defined for UDP in RFC 3095 [2]. In addition, it is desirable to include some of the improvements found in the ROHC IP- Only profile [3]. Finally, whenever UDP-Lite is used in a manner that is semantically identical to UDP, the compression efficiency should be similar.
簡単さはUDP-Liteヘッダー圧縮プロフィールのデザインに関する強い動機です。 UDP-Liteのために定義されたプロフィールはRFC3095[2]でUDPのために定義された対応するプロフィールへのほんのいくつかの簡単な変更を伴うはずです。 さらに、ROHC IPだけプロフィール[3]で見つけられた改良のいくつかを含んでいるのは望ましいです。 最終的に、UDP-LiteがUDPと意味的に同じ方法で使用されるときはいつも、圧縮効率は同様であるべきです。
4.2. ROHC Considerations
4.2. ROHC問題
The simplest approach to the definition of ROHC profiles for UDP-Lite is to treat the Checksum Coverage field as an irregular value, and to send it uncompressed for every packet. This may be achieved simply by adding the field to the definition of the general packet format [2]. However, then the compression efficiency would always be less than for UDP.
UDP-LiteのためのROHCプロフィールの定義への最も簡単なアプローチが不規則な値としてChecksum Coverage分野を扱うことであり、それを送るのはあらゆるパケットのために解凍しました。 これは、単に一般的なパケット・フォーマット[2]の定義に分野を加えることによって、達成されるかもしれません。 しかしながら、その時、圧縮効率はUDPよりいつも少ないでしょう。
Some care should be given to achieve compression efficiency for UDP- Lite similar to that for UDP when the Checksum Coverage field behaves like the UDP Length field. This requires the possibility to infer the Checksum Coverage field when it is equal to the length of the packet. Otherwise, this would put the UDP-Lite protocol at a disadvantage over links where header compression is used, when its behavior is made similar to the semantics of UDP.
Checksum Coverage分野がUDP Length分野のように振る舞うとき、UDPに、それと同様のUDP- Liteのために圧縮効率を達成するために何らかの注意を与えるべきです。 これはそれがパケットの長さと等しいときにChecksum Coverage分野を推論する可能性を必要とします。 さもなければ、これはヘッダー圧縮が使用されているリンクの上の不利な立場にUDP-Liteプロトコルを置くでしょう、振舞いをUDPの意味論と同様にするとき。
A mechanism to detect the presence of the Checksum Coverage field in compressed headers is thus needed. This is achieved by defining a new packet type with the identifiers left unused in RFC 3095 [2].
圧縮されたヘッダーでのChecksum Coverage分野の存在を検出するメカニズムがこのようにして必要です。 これは、RFC3095[2]で未使用で残っている識別子で新しいパケットタイプを定義することによって、達成されます。
5. ROHC Profiles for UDP-Lite
5. UDP-LiteのためのROHCプロフィール
This section defines two ROHC profiles:
このセクションは2個のROHCプロフィールを定義します:
- RTP/UDP-Lite/IP compression (profile 0x0007)
- UDP-Lite/IP compression (profile 0x0008)
- RTP/UDP-Lite/IP圧縮(プロフィール0x0007)--UDP-Lite/IP圧縮(プロフィール0x0008)
Pelletier Standards Track [Page 6] RFC 4019 ROHC: Profiles for UDP-Lite April 2005
ペレティアStandardsはRFC4019ROHCを追跡します[6ページ]: UDP-Liteのために、2005年4月の輪郭を描きます。
These profiles build on the specifications found in RFC 3095 [2], with as little modification as possible. Unless it is explicitly stated otherwise, the profiles defined herein follow the specifications of ROHC UDP and ROHC RTP, respectively.
これらのプロフィールは同じくらい少ない変更が可能な状態でRFC3095[2]で見つけられた仕様に建てられます。 それが別の方法で明らかに述べられない場合、ここに定義されたプロフィールはそれぞれROHC UDPとROHC RTPの仕様に従います。
Note also that this document reuses the notation found in [2].
また、このドキュメントが[2]で見つけられた記法を再利用することに注意してください。
5.1. Context Parameters
5.1. 文脈パラメタ
As described in [2], information about previous packets is maintained in a context. This includes information describing the packet stream and compression parameters. Although the UDP and UDP-Lite protocols share many commonalities, the differences in semantics as described earlier render the following parameter inapplicable:
[2]で説明されるように、前のパケットの情報は文脈で保守されます。 これはパケットの流れと圧縮パラメタについて説明する情報を含んでいます。 UDPとUDP-Liteプロトコルは多くの共通点を共有しますが、より早く説明される意味論の違いは以下のパラメタを不適当に表します:
The parameter context(UDP Checksum)
パラメタ文脈(UDPチェックサム)
The UDP-Lite checksum cannot be disabled, as opposed to UDP. The
parameter context(UDP Checksum) defined in [2] (section 5.7) is
therefore not used for compression of UDP-Lite.
UDPと対照的にUDP-Liteチェックサムを無効にすることができません。 したがって、[2](セクション5.7)で定義されたパラメタ文脈(UDP Checksum)はUDP-Liteの圧縮に使用されません。
In addition, the UDP-Lite checksum is always sent as-is in every compressed packet. However, the Checksum Coverage field may not always be sent in each compressed packet, and the following context parameter is used to indicate whether the field is sent:
さらに、あらゆる圧縮されたパケットでいつもそのままでUDP-Liteチェックサムを送ります。 しかしながら、それぞれの圧縮されたパケットでいつもChecksum Coverage野原を送るかもしれないというわけではありません、そして、野原が送られるかどうかを示すのに以下の文脈パラメタを使用します:
The parameter context(UDP-Lite Coverage Field Present)
パラメタ文脈(UDP-Lite適用範囲分野プレゼント)
Whether the UDP-Lite Checksum Coverage field is present or not in
the general packet format (see section 5.3.1) is controlled by the
value of the Coverage Field Present (CFP) flag in the context.
UDP-Lite Checksum Coverage分野が一般的なパケット・フォーマットで存在しているかどうかが(セクション5.3.1を見てください)文脈のCoverage Field Present(CFP)旗の値によって制御されます。
If context(CFP) is nonzero, the Checksum Coverage field is not
compressed, and it is present within compressed packets. If
context(CFP) is zero, the Checksum Coverage field is compressed,
and it is not sent. This is the case when the value of the
Checksum Coverage field follows a stable inter-packet change
pattern; the field has either a constant value or it has a value
equal to the packet length for most packets in a sequence (see
section 3.2).
文脈(CFP)が非零であるなら、Checksum Coverage分野は圧縮されません、そして、それは圧縮されたパケットの中に存在しています。 文脈(CFP)がゼロであるなら、Checksum Coverage分野は圧縮されます、そして、それは送られません。 Checksum Coverage分野の値が安定した相互パケット変化パターンに従うとき、これはそうです。 分野には、恒常価値があるか、または次々に、それにほとんどのパケットに、パケット長と等しい値があります(セクション3.2を見てください)。
Finally, the following context parameter is needed to indicate whether the field should be inferred or taken from a value previously saved in the context:
最終的に、以下の文脈パラメタを分野が推論されるべきであるかどうかを示すのが必要である、または以前に文脈で節約された値から取ります:
Pelletier Standards Track [Page 7] RFC 4019 ROHC: Profiles for UDP-Lite April 2005
ペレティアStandardsはRFC4019ROHCを追跡します[7ページ]: UDP-Liteのために、2005年4月の輪郭を描きます。
The parameter context(UDP-Lite Coverage Field Inferred)
パラメタ文脈(推論されたUDP-Lite適用範囲分野)
When the UDP-Lite Checksum Coverage field is not present in the
compressed header (CFP=0), whether it is inferred is controlled by
the value of the Coverage Field Inferred (CFI) flag in the context.
UDP-Lite Checksum Coverage分野が圧縮されたヘッダー(CFP=0)に存在していないとき、それが推論されるかどうかが文脈のCoverage Field Inferred(CFI)旗の値によって制御されます。
If context(CFI) is nonzero, the Checksum Coverage field is inferred
from the packet length, similarly as for the UDP Length field in
ROHC RTP. If context(CFI) is zero, the Checksum Coverage field is
decompressed by using context(UDP-Lite Checksum Coverage).
Therefore, when context(CFI) is updated to a nonzero value, the
value of the Checksum Coverage field stored in the context must
also be updated.
文脈(CFI)が非零であるなら、Checksum Coverage分野はROHC RTPのUDP Length分野のようにパケット長から同様に推論されます。 文脈(CFI)がゼロであるなら、Checksum Coverage分野は、文脈(UDP-Lite Checksum Coverage)を使用することによって、減圧されます。 したがって、また、文脈(CFI)を非ゼロ値にアップデートするとき、文脈に格納されたChecksum Coverage野原の値をアップデートしなければなりません。
5.2. Initialization
5.2. 初期設定
Unless it is stated otherwise, the mechanisms of ROHC RTP and ROHC UDP found in [2] are used also for the ROHC RTP/UDP-Lite and the ROHC UDP-Lite profiles, respectively.
また、それが別の方法で述べられない場合、[2]で見つけられたROHC RTPとROHC UDPのメカニズムはROHC RTP/UDP-LiteとROHC UDP-Liteプロフィールにそれぞれ使用されます。
In particular, the considerations of ROHC UDP regarding the UDP SN taking the role of the RTP Sequence Number apply to ROHC UDP-Lite. Also, the static context for ROHC UDP-Lite may be initialized by reusing an existing context belonging to a stream compressed by using ROHC RTP/UDP-Lite (profile 0x0007), similarly as for ROHC UDP.
特に、RTP Sequence Numberの役割を果たすUDP SNに関するROHC UDPの問題はROHC UDP-Liteに適用されます。 また、ROHC UDP-Liteのための静的な関係は、ROHC UDPのように同様に、ROHC RTP/UDP-Lite(プロフィール0x0007)を使用することによって圧縮された流れに属す既存の文脈を再利用することによって、初期化されるかもしれません。
5.2.1. Initialization of the UDP-Lite Header [1]
5.2.1. UDP-Liteヘッダーの初期設定[1]
The structure of the IR and IR-DYN packets and the initialization procedures are the same as for the ROHC profiles for UDP [2], with the exception of the dynamic part as specified for UDP. A 2-octet field containing the checksum coverage is added before the Checksum field. This affects the format of dynamic chains in both IR and IR- DYN packets.
IRの構造、IR-DYNパケット、および初期化手順はUDP[2]のためのROHCプロフィールのように同じです、UDPのための指定されるとしてのダイナミックな部分を除いて。 チェックサム適用範囲を含む2八重奏の分野はChecksum分野の前に加えられます。 これは両方のIRとIR DYNパケットのダイナミックなチェーンの形式に影響します。
Dynamic part:
ダイナミックな部分:
+---+---+---+---+---+---+---+---+
/ Checksum Coverage / 2 octets
+---+---+---+---+---+---+---+---+
/ Checksum / 2 octets
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+/チェックサムCoverage / 2八重奏+---+---+---+---+---+---+---+---+/チェックサム/2つの八重奏+---+---+---+---+---+---+---+---+
CRC-DYNAMIC: Checksum Coverage field, Checksum field (octets 5 - 8).
CRC-動力: Coverageがさばくチェックサム、Checksum分野(八重奏5--8)。
CRC-STATIC: All other fields (octets 1 - 4).
CRC-静電気: 他のすべての分野(八重奏1--4)。
Pelletier Standards Track [Page 8] RFC 4019 ROHC: Profiles for UDP-Lite April 2005
ペレティアStandardsはRFC4019ROHCを追跡します[8ページ]: UDP-Liteのために、2005年4月の輪郭を描きます。
5.2.2. Compressor and Decompressor Logic
5.2.2. コンプレッサーと減圧装置論理
The following logic must be used by both the compressor and the decompressor for assigning values to the parameters context(CFP) and context(CFI) during initialization:
初期化の間、パラメタ文脈(CFP)と文脈(CFI)に値を割り当てるのにコンプレッサーと減圧装置の両方で以下の論理を使用しなければなりません:
Context(CFP)
文脈(CFP)
During context initialization, the value of context(CFP) MUST be
set to a nonzero value if the Checksum Coverage field differs from
the length of the UDP-Lite packet, for any one IR or IR-DYN packet
sent (compressor) or received (decompressor); otherwise, the value
MUST be set to zero.
文脈初期化の間、Checksum Coverage分野がUDP-Liteパケットの長さと異なっているなら、文脈(CFP)の値を非ゼロ値に設定しなければなりません、どんなIRかIR-DYNパケットも発信したか(コンプレッサー)、または受信されたので(減圧装置)。 さもなければ、ゼロに値を設定しなければなりません。
Context(CFI)
文脈(CFI)
During context initialization, the value of context(CFI) MUST be
set to a nonzero value if the Checksum Coverage field is equal to
the length of the UDP-Lite packet within an IR or an IR-DYN packet
sent (compressor) or received (decompressor); otherwise, the value
MUST be set to zero.
文脈初期化の間、Checksum Coverage分野がIRの中でUDP-Liteパケットの長さと等しいなら文脈(CFI)の値を非ゼロ値に設定しなければならないか、またはIR-DYNパケットは、発信したか(コンプレッサー)、受信されました(減圧装置)。 さもなければ、ゼロに値を設定しなければなりません。
5.3. Packet Formats
5.3. パケット・フォーマット
The general packet format, as defined in RFC 3095 [2], is modified to include an additional field for the UDP-Lite checksum coverage. A packet type is also defined to handle the specific semantics and characteristics of this field.
RFC3095[2]で定義される一般的なパケット・フォーマットは、UDP-Liteチェックサム適用範囲への追加分野を含むように変更されます。 また、パケットタイプは、この分野の特定の意味論と特性を扱うために定義されます。
5.3.1. General Packet Format
5.3.1. 一般パケット・フォーマット
The general packet format of a compressed ROHC UDP-Lite header is similar to the compressed ROHC RTP header ([2], section 5.7), with modifications to the Checksum field, as well as additional fields for handling multiple IP headers and for the UDP-Lite checksum coverage:
圧縮されたROHC UDP-Liteヘッダーの一般的なパケット・フォーマットは圧縮されたROHC RTPヘッダー([2]、Checksum分野への変更によって複数のIPヘッダーを扱って、UDP-Liteチェックサム適用範囲への追加分野と同じくらい良いセクション5.7と同様です:
Pelletier Standards Track [Page 9] RFC 4019 ROHC: Profiles for UDP-Lite April 2005
ペレティアStandardsはRFC4019ROHCを追跡します[9ページ]: UDP-Liteのために、2005年4月の輪郭を描きます。
--- --- --- --- --- --- --- ---
: List of : variable, given by static chain
/ dynamic chains / (does not include SN)
: for additional IP headers : see also [3], section 3.2.
--- --- --- --- --- --- --- ---
: : 2 octets,
+ UDP-Lite Checksum Coverage + if context(CFP) = 1 or
: : if packet type = CCE (see 5.3.2)
--- --- --- --- --- --- --- ---
: :
+ UDP-Lite Checksum + 2 octets
: :
--- --- --- --- --- --- --- ---
--- --- --- --- --- --- --- --- : 以下のリスト 変数静的なチェーン/ダイナミックなチェーン/(SNを含んでいません)が考えて、 追加IPヘッダーのために: また、[3]、セクション3.2を見てください。 --- --- --- --- --- --- --- --- : : または、2つの八重奏であり、+ UDP-Lite Checksum Coverage+が文脈(CFP)であるなら1と等しい、: : パケットタイプがCCEと等しいなら(5.3に.2を見てください)--- --- --- --- --- --- --- --- : : + UDP-Lite Checksum+2つの八重奏: : --- --- --- --- --- --- --- ---
The list of dynamic header chains carries the dynamic header part for each IP header in excess of the initial two, if there is any (as indicated by the presence of corresponding header parts in the static chain). Note that there is no sequence number at the end of the chain, as SN is present within compressed base headers.
ダイナミックなヘッダーチェーンのリストはそれぞれのIPヘッダーのために初期の2を超えてダイナミックなヘッダー部分を運びます、いずれかあれば(静的なチェーンにおける、対応するヘッダーの部品の存在によって示されるように)。 一連番号が全くチェーンの端にないことに注意してください、SNが圧縮されたベースヘッダーの中に存在しているとき。
The order of the fields following the optional extension of the general ROHC packet format is the same as the order between the fields in the uncompressed header.
一般的なROHCパケット・フォーマットの任意の拡大に続く分野の注文は解凍されたヘッダーの分野の間のオーダーと同じです。
When the CRC is calculated, the Checksum Coverage field is CRC- DYNAMIC.
CRCが計算されるとき、Checksum Coverage分野はCRC- DYNAMICです。
5.3.2. Packet Type CCE: CCE(), CCE(ON), and CCE(OFF)
5.3.2. パケットタイプCCE: CCE()、CCE(ON)、およびCCE(OFF)
The ROHC profiles for UDP-Lite define a packet type to handle the various possible change patterns of the checksum coverage. This packet type may be used to manipulate the context values that control the presence of the Checksum Coverage field within the general packet format (i.e., context(CFP)) and how the field is decompressed (i.e., context(CFI)). The 2-octet Checksum Coverage field is always present within the format of this packet (see section 5.3.1).
UDP-LiteのためのROHCプロフィールは、チェックサム適用範囲の様々な可能な変化パターンを扱うためにパケットタイプを定義します。 このパケットタイプは、一般的なパケット・フォーマットの中でChecksum Coverage分野の存在を制御する文脈値(すなわち、文脈(CFP))と分野がどう減圧されるかを(すなわち、文脈(CFI))操るのに使用されるかもしれません。 2八重奏のChecksum Coverage分野はこのパケットの形式の中にいつも存在しています(セクション5.3.1を見てください)。
This type of packet is named Checksum Coverage Extension, or CCE, and its updating properties depend on the final two bits of the packet type octet (see format below). A naming scheme of the form CCE(<some_property>) is used to uniquely identify the properties of a particular CCE packet.
このタイプのパケットはChecksum Coverage Extension、またはCCEと命名されます、そして、アップデートの特性はパケットタイプ八重奏の最終的な2ビットに依存します(以下の形式を見てください)。 フォームCCEの命名計画、(<、何らかの_の特性の>) 唯一特定のCCEパケットの特性を特定するために、使用されます。
Although this packet type defines its own format, it may be considered as an extension mechanism for packets of type 2, 1, or 0 [2]. This is achieved by substitution of the packet type identifier of the first octet of the base header (the "outer" identifier) with
このパケットタイプはそれ自身の書式を定義しますが、それはタイプ2、1、または0[2]のパケットのための拡大メカニズムであるとみなされるかもしれません。 これはベースヘッダー(「外側」の識別子)の最初の八重奏に関するパケットタイプ識別子の代替で達成されます。
Pelletier Standards Track [Page 10] RFC 4019 ROHC: Profiles for UDP-Lite April 2005
ペレティアStandardsはRFC4019ROHCを追跡します[10ページ]: UDP-Liteのために、2005年4月の輪郭を描きます。
one of the unused packet types from RFC 3095 [2]. The substituted identifier is then moved to the first octet of the remainder of the base header (the "inner" identifier).
未使用のパケットの1つはRFC3095[2]からタイプされます。 そして、代入された識別子はベースヘッダー(「内側」の識別子)の残りの最初の八重奏に動かされます。
The format of the ROHC UDP-Lite CCE packet type is as follows:
ROHC UDP-Lite CCEパケットタイプの形式は以下の通りです:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 F | K | Outer packet type identifier
+===+===+===+===+===+===+===+===+
: : (with inner type identifier)
/ Inner Base header / variable number of bits, given by
: : the inner packet type identifier
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 0F| K| 外側のパケットタイプ識別子+===+===+===+===+===+===+===+===+ : : (内側のタイプ識別子がある) 以下によって与えられた/内側の基地ヘッダー/可変な数のビット : 内側のパケットタイプ識別子+---+---+---+---+---+---+---+---+
F,K: F,K = 00 is reserved at framework level (IR-DYN);
F,K = 01 indicates CCE();
F,K = 10 indicates CCE(ON);
F,K = 11 indicates CCE(OFF).
F、K: F、K=00は枠組みのレベル(IR-DYN)で予約されます。 F、K=01はCCE()を示します。 F、K=10はCCE(ON)を示します。 F、K=11はCCE(OFF)を示します。
Updating properties: The updating properties of the inner packet
type carried within any of the CCE packets are always
maintained. CCE(ON) and CCE(OFF) MUST NOT be used to extend
R-0 and R-1* headers. In addition, CCE(ON) always updates
context(CFP); CCE(OFF) always updates context(CFP),
context(CFI), and context(UDP-Lite Checksum Coverage).
特性をアップデートします: CCEパケットのどれかの中で運ばれた内側のパケットタイプのアップデートの特性はいつも維持されます。 R-0とR-1*ヘッダーを広げるのにCCE(ON)とCCE(OFF)を使用してはいけません。 さらに、CCE(ON)はいつも文脈(CFP)をアップデートします。 CCE(OFF)はいつも文脈(CFP)、文脈(CFI)、および文脈(UDP-Lite Checksum Coverage)をアップデートします。
Appendix B provides an expanded view of the resulting format of the CCE packet type.
付録BはCCEパケットタイプの結果として起こる形式の拡張意見を提供します。
5.3.2.1. Properties of CCE()
5.3.2.1. CCEの特性()
Aside from the updating properties of the inner packet type carried within CCE(), this packet does not update any other context values. CCE() thus is mode-agnostic; e.g., it can extend any of packet types 2, 1, and 0, regardless of the current mode of operation [2].
CCE()の中で運ばれた内側のパケットタイプのアップデートの特性は別として、このパケットはいかなる他の文脈値もアップデートしません。 その結果、CCE()はモード不可知論者です。 例えば、それは操作[2]の現在のモードにかかわらずパケットタイプ2、1、および0のいずれも広げることができます。
CCE() may be used when the checksum coverage deviates from the change pattern assumed by the compressor, where the field could previously be compressed. This packet is useful if the occurrence of such deviations is rare.
チェックサム適用範囲が以前に分野を圧縮できたコンプレッサーによって想定された変化パターンから逸れるとき、CCE()は使用されるかもしれません。 そのような逸脱の発生がまれであるなら、このパケットは役に立ちます。
5.3.2.2. Properties of CCE(ON)
5.3.2.2. CCEの特性(ON)
In addition to the updating properties of the inner packet type, CCE(ON) updates context(CFP) to a nonzero value; i.e., it effectively turns on the presence of the Checksum Coverage field within the
内側のパケットタイプのアップデートの特性に加えて、CCE(ON)は文脈(CFP)を非ゼロ値にアップデートします。 事実上、すなわち、それは中でChecksum Coverage分野の存在をつけます。
Pelletier Standards Track [Page 11] RFC 4019 ROHC: Profiles for UDP-Lite April 2005
ペレティアStandardsはRFC4019ROHCを追跡します[11ページ]: UDP-Liteのために、2005年4月の輪郭を描きます。
general packet format. This is useful when the predominant change pattern of the checksum coverage precludes its compression.
一般的なパケット・フォーマット。 チェックサム適用範囲の支配的な変化パターンが圧縮を排除するとき、これは役に立ちます。
CCE(ON) can extend any of the context-updating packets of type 2, 1, and 0; that is, packets with a compressed header containing a CRC [2]. Specifically, R-0 and R-1* headers MUST NOT be extended by using CCE(ON).
CCE(ON)はタイプ2、1、および0の文脈をアップデートするパケットのどれかを広げることができます。 すなわち、圧縮されたヘッダーがCRC[2]を含んでいるパケット。 明確に、CCE(ON)を使用することによって、R-0とR-1*ヘッダーを広げてはいけません。
5.3.2.3. Properties of CCE(OFF)
5.3.2.3. CCEの特性(OFF)
In addition to the updating properties of the inner packet type, CCE(OFF) updates context(CFP) to a value of zero; i.e., it effectively turns off the presence of the Checksum Coverage field within the general packet format. This is useful when the change pattern of the checksum coverage seldom deviates from the pattern assumed by the compressor.
内側のパケットタイプのアップデートの特性に加えて、CCE(OFF)は文脈(CFP)をゼロの値にアップデートします。 事実上、すなわち、それは一般的なパケット・フォーマットの中でChecksum Coverage分野の存在をオフにします。 チェックサム適用範囲の変化パターンがコンプレッサーによって想定されたパターンからめったに逸れないとき、これは役に立ちます。
CCE(OFF) also updates context(CFI) to a nonzero value, if field(UDP- Lite Checksum Coverage) is equal to the packet length; otherwise, it must be set to zero. Note that when context(CFI) is updated by using packet type CCE(OFF), a match of field(Checksum Coverage) with the packet length always has precedence over a match with context(Checksum Coverage). Finally, context(UDP-Lite Checksum Coverage) is also updated by CCE(OFF).
また、分野(UDP- Lite Checksum Coverage)がパケット長と等しいなら、CCE(OFF)は文脈(CFI)を非ゼロ値にアップデートします。 さもなければ、ゼロにそれを設定しなければなりません。 パケットタイプCCE(OFF)を使用することによって文脈(CFI)をアップデートするときパケット長がある分野(チェックサムCoverage)のマッチには文脈(チェックサムCoverage)との照合の上の先行がいつもあることに注意してください。 また、最終的に、文脈(UDP-Lite Checksum Coverage)はCCE(OFF)によってアップデートされます。
Similarly to CCE(ON), CCE(OFF) can extend any of the context updating packets of type 2, 1, and 0 [2].
同様に、CCE(ON)に、CCE(OFF)はタイプ2、1、および0[2]のパケットをアップデートする文脈のいずれも与えることができます。
5.4. Compressor Logic
5.4. コンプレッサー論理
If hdr(UDP-Lite Checksum Coverage) is different from context(UDP-Lite Checksum Coverage) and different from the packet length when context(CFP) is zero, the Checksum Coverage field cannot be compressed. In addition, if hdr(UDP-Lite Checksum Coverage) is different from the packet length when context(CFP) is zero and context(CFI) is nonzero, the Checksum Coverage field cannot be compressed by either. For both cases, the field must be sent uncompressed using a CCE packet, or the context must be reinitialized by using an IR packet.
文脈(CFP)がゼロであるときに、hdr(UDP-Lite Checksum Coverage)が文脈(UDP-Lite Checksum Coverage)と異なってパケット長と異なるなら、Checksum Coverage分野を圧縮できません。 さらに、文脈(CFP)がゼロであるときに、hdr(UDP-Lite Checksum Coverage)がパケット長と異なっていて、文脈(CFI)が非零であるなら、どちらもChecksum Coverage分野を圧縮できません。 両方のケースにおいて、CCEパケットを使用することで解凍されていた状態で野原を送らなければなりませんか、またはIRパケットを使用することによって、文脈を再初期化しなければなりません。
5.5. Decompressor Logic
5.5. 減圧装置論理
For packet types other than IR, IR-DYN, and CCE that are received when the value of context(CFP) is zero, the Checksum Coverage field must be decompressed by using the value stored in the context if the value of context(CFI) is zero; otherwise, the field is inferred from the length of the UDP-Lite packet derived from the IP module.
IR以外のパケットタイプ、IR-DYN、および文脈(CFP)の値がゼロであるときに受け取られていているCCEに関しては、文脈(CFI)の値がゼロであるなら文脈に格納された値を使用することによって、Checksum Coverage分野を減圧しなければなりません。 さもなければ、分野はIPモジュールから得られたUDP-Liteパケットの長さから推論されます。
Pelletier Standards Track [Page 12] RFC 4019 ROHC: Profiles for UDP-Lite April 2005
ペレティアStandardsはRFC4019ROHCを追跡します[12ページ]: UDP-Liteのために、2005年4月の輪郭を描きます。
5.6. Additional Mode Transition Logic
5.6. 追加モード変遷論理
The profiles defined in this document allow the compressor to decline a mode transition requested by the decompressor. This is achieved by redefining the Mode parameter for the value mode = 0 (in packet types UOR-2, IR, and IR-DYN) as follows (see also [3], section 3.4):
本書では定義されたプロフィールで、コンプレッサーは減圧装置によって要求されたモード変遷を断つことができます。 これは以下の値のモード=0(パケットタイプのUOR-2、IR、およびIR-DYNによる)のためのModeパラメタを再定義することによって、達成されます(また、[3]を見てください、セクション3.4):
Mode: Compression mode. 0 = (C)ancel Mode Transition
モード: 圧縮モード。 0 =(C)ancelモード変遷
Upon receiving the Mode parameter set to 0, the decompressor MUST stay in its current mode of operation and SHOULD refrain from sending further mode transition requests for the declined mode.
Modeパラメタセットを0に受けると、減圧装置は操作の現在のモードで残らなければなりません、そして、SHOULDは傾けられたモードを求めるさらなるモード変遷要求を送るのを控えます。
5.7. The CONTEXT_MEMORY Feedback Option
5.7. 文脈_メモリフィードバックオプション
This feedback option informs the compressor that the decompressor does not have sufficient memory resources to handle the context of the packet stream required by the current compressed structure.
このフィードバックオプションは、減圧装置には現在の圧迫構造によって必要とされたパケットの流れの文脈を扱うことができるくらいのメモリリソースがないことをコンプレッサーに知らせます。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type = 9 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | タイプ=9を選んでください。| レン=0を選んでください。| +---+---+---+---+---+---+---+---+
When receiving a CONTEXT_MEMORY option, the compressor SHOULD take actions to compress the packet stream in a way that requiring less decompressor memory resources or stop compressing the packet stream.
CONTEXT_MEMORYオプションを受け取るとき、コンプレッサーSHOULDは、より少ない減圧装置を必要として、メモリリソースかパケットを圧縮する停止が流れる方法でパケットの流れを圧縮するために行動を取ります。
5.8. Constant IP-ID
5.8. 一定のIP-ID
The profiles for UDP-Lite support compression of the IP-ID field with constant behavior, with the addition of the Static IP Identifier (SID) flag within the dynamic part of the chain used to initialize the IPv4 header, as follows (see also [3], section 3.3):
UDP-Liteのためのプロフィールは一定の振舞いによるIP-ID分野の圧縮を支持します、チェーンのダイナミックな部分の中のStatic IP Identifier(SID)旗の添加がIPv4ヘッダーを初期化するのに使用されている状態で、以下の通りです(また、[3]を見てください、セクション3.3):
Dynamic part:
ダイナミックな部分:
+---+---+---+---+---+---+---+---+
| Type of Service |
+---+---+---+---+---+---+---+---+
| Time to Live |
+---+---+---+---+---+---+---+---+
/ Identification / 2 octets
+---+---+---+---+---+---+---+---+
| DF|RND|NBO|SID| 0 |
+---+---+---+---+---+---+---+---+
/ Generic extension header list / variable length
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+ | サービスのタイプ| +---+---+---+---+---+---+---+---+ | 生きる時間| +---+---+---+---+---+---+---+---+/識別/2つの八重奏+---+---+---+---+---+---+---+---+ | DF|RND|NBO|シド| 0 | +---+---+---+---+---+---+---+---+ /ジェネリック拡張ヘッダーリスト/可変長+---+---+---+---+---+---+---+---+
Pelletier Standards Track [Page 13] RFC 4019 ROHC: Profiles for UDP-Lite April 2005
ペレティアStandardsはRFC4019ROHCを追跡します[13ページ]: UDP-Liteのために、2005年4月の輪郭を描きます。
SID: Static IP Identifier.
シド: 静的なIP識別子。
For IR and IR-DYN packets:
IRとIR-DYNパケットのために:
The logic is the same as that for the respective ROHC
profiles for UDP, with the addition that field (SID)
must be kept in the context.
論理はUDPのためのそれぞれのROHCプロフィールのためのそれと同じです、文脈で分野(SID)を保たなければならない添加で。
For compressed headers other than IR and IR-DYN:
IR以外の圧縮されたヘッダーとIR-DYNのために:
If value(RND) = 0 and context(SID) = 0, hdr(IP-ID) is
compressed by using Offset IP-ID encoding (see [2], section
4.5.5) using p = 0 and default-slope(IP-ID offset) = 0.
値(RND)が0と文脈(SID)=0と等しいなら、hdr(IP-ID)は、pを使用する=0をコード化する([2]、セクション4.5.5を見ます)Offset IP-IDとデフォルトスロープ(IP-IDは相殺された)=0を使用することによって、圧縮されます。
If value(RND) = 0 and context(SID) = 1, hdr(IP-ID) is constant
and compressed away; hdr(IP-ID) is the value of context(IP-ID).
値(RND)が0と文脈(SID)=1と等しいなら、hdr(IP-ID)は遠くに一定で圧縮されています。 hdr(IP-ID)は文脈(IP-ID)の値です。
If value(RND) = 1, IP-ID is the uncompressed hdr(IP-ID). IP-ID
is then passed as additional octets at the end of the
compressed header, after any extensions.
値(RND)=1であるなら、IP-IDは解凍されたhdr(IP-ID)です。 そして、IP-IDはどんな拡大の後にも追加八重奏として圧縮されたヘッダーの端を通り過ぎられます。
Note: Only IR and IR-DYN packets can update context(SID).
以下に注意してください。 IRとIR-DYNパケットだけが文脈(SID)をアップデートできます。
Note: All other fields are the same as for the respective ROHC profiles for UDP [2].
以下に注意してください。 他のすべての分野がUDP[2]のためのそれぞれのROHCプロフィールのように同じです。
6. Security Considerations
6. セキュリティ問題
The security considerations of RFC 3095 [2] apply integrally to this document, without modification.
RFC3095[2]のセキュリティ問題は変更なしでこのドキュメントに不可欠に適用されます。
7. IANA Considerations
7. IANA問題
ROHC profile identifiers 0x0007 (ROHC RTP/UDP-Lite) and 0x0008 (ROHC UDP-Lite) have been reserved by the IANA for the profiles defined in this document (RFC 4019).
ROHCプロフィール識別子0x0007(ROHC RTP/UDP-Lite)と0×0008(ROHC UDP-Lite)は本書では定義されたプロフィール(RFC4019)のためにIANAによって予約されました。
Two ROHC profile identifiers must be reserved by the IANA for the profiles defined in this document. Since profile number 0x0006 is being saved for the TCP/IP (ROHC-TCP) profile, profile numbers 0x0007 and 0x0008 are the most suitable unused identifiers available, and should thus be used. As for previous ROHC profiles, profile numbers 0xnn07 and 0xnn08 must also be reserved for future variants of these profiles. The registration suggested for the "RObust Header Compression (ROHC) Profile Identifiers" name space:
IANAは本書では定義されたプロフィールのために2つのROHCプロフィール識別子を予約しなければなりません。 プロフィールNo.0x0006がTCP/IP(ROHC-TCP)プロフィールのために節約されているので、プロフィールNo.0×0007と0x0008は、利用可能な最も適当な未使用の識別子であり、その結果、使用されるべきです。 また、前のROHCプロフィールに関して、これらのプロフィールの将来の異形のためにプロフィール番号の0xnn07と0xnn08を予約しなければなりません。 登録はスペースという「体力を要しているヘッダー圧縮(ROHC)プロフィール識別子」名のために示されました:
Pelletier Standards Track [Page 14] RFC 4019 ROHC: Profiles for UDP-Lite April 2005
ペレティアStandardsはRFC4019ROHCを追跡します[14ページ]: UDP-Liteのために、2005年4月の輪郭を描きます。
OLD: 0x0006-0xnn7F To be Assigned by IANA
古い: 0×0006 0xnn7F Toであることが、IANAによるAssignedです。
NEW: 0xnn06 To be Assigned by IANA
0x0007 ROHC RTP/UDP-Lite [RFC4019]
0xnn07 Reserved
0x0008 ROHC UDP-Lite [RFC4019]
0xnn08 Reserved
0x0009-0xnn7F To be Assigned by IANA
新しい: 0xnn06 To、IANA0x0007ROHC RTP/UDP-Lite[RFC4019]0xnn07 Reserved0x0008ROHC UDP-Lite[RFC4019]0xnn08 ReservedによるAssignedが0×0009 0xnn7F Toであったなら、IANAで、Assignedになってください。
8. Acknowledgments
8. 承認
The author would like to thank Lars-Erik Jonsson, Kristofer Sandlund, Mark West, Richard Price, Gorry Fairhurst, Fredrik Linstroem and Mats Nordberg for useful reviews and discussions around this document.
作者はこのドキュメントの周りで役に立つレビューと議論についてラース-エリック・イェンソン、クリストファSandlund、マーク西洋、リチャードPrice、ゴーリーFairhurst、フレドリックLinstroem、およびマッツ・ノールベルグに感謝したがっています。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] 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.
[2] ボルマン、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日
[3] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
(ROHC): A Compression Profile for IP", RFC 3843, June 2004.
[3] イェンソン、L-E.、およびG.ペレティア、「体力を要しているヘッダー圧縮(ROHC):」 「IPのための圧縮プロフィール」、RFC3843、2004年6月。
[4] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G.
Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)",
RFC 3828, July 2004.
[4]Larzon、L-A.、デーゲルマルク、M.、ピンク、S.、イェンソン、L-E.、およびG.Fairhurst、「軽量のユーザー・データグラム・プロトコル(UDP-Lite)」、RFC3828 2004年7月。
9.2. Informative References
9.2. 有益な参照
[5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[5] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[6] デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[7] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[7] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
Pelletier Standards Track [Page 15] RFC 4019 ROHC: Profiles for UDP-Lite April 2005
ペレティアStandardsはRFC4019ROHCを追跡します[15ページ]: UDP-Liteのために、2005年4月の輪郭を描きます。
[8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[8]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
Pelletier Standards Track [Page 16] RFC 4019 ROHC: Profiles for UDP-Lite April 2005
ペレティアStandardsはRFC4019ROHCを追跡します[16ページ]: UDP-Liteのために、2005年4月の輪郭を描きます。
Appendix A. Detailed Classification of Header Fields
ヘッダーフィールドの付録A.詳細な分類
This section summarizes the difference from the classification found in the corresponding appendix in RFC 3095 [2] and similarly provides conclusions about how the various header fields should be handled by the header compression scheme to optimize compression and functionality. These conclusions are separated based on the behavior of the UDP-Lite Checksum Coverage field and use the expected change patterns described in section 3.2 of this document.
このセクションは、RFC3095[2]に対応する付録で見つけられた分類から違いをまとめて、様々なヘッダーフィールドがヘッダー圧縮技術によってどう扱われるか、そして、圧縮と機能性を最適化するべきであることに関して同様に結論を提供します。 これらの結論は、UDP-Lite Checksum Coverage分野の振舞いに基づいて切り離されて、このドキュメントのセクション3.2で説明された予想された変化パターンを使用します。
A.1. UDP-Lite Header Fields
A.1。 UDP-Liteヘッダーフィールド
The following table summarizes a possible classification for the UDP- Lite header fields in comparison with the classification for UDP, using the same classes as in RFC 3095 [2].
以下のテーブルはUDPのために分類との比較におけるUDP- Liteヘッダーフィールドのための可能な分類をまとめて、同じくらい使用するのはRFC3095[2]のように属します。
Header fields of UDP-Lite and UDP:
UDP-LiteとUDPのヘッダーフィールド:
+-------------------+-------------+
| UDP-Lite | UDP |
+-------------------+--------+-------------------+-------------+
| Header | Size | Class | Class |
| Field | (bits) | | |
+-------------------+--------+-------------------+-------------+
| Source Port | 16 | STATIC-DEF | STATIC-DEF |
| Destination Port | 16 | STATIC-DEF | STATIC-DEF |
| Checksum Coverage | 16 | INFERRED | |
| | | STATIC | |
| | | CHANGING | |
| Length | 16 | | INFERRED |
| Checksum | 16 | CHANGING | CHANGING |
+-------------------+--------+-------------------+-------------+
+-------------------+-------------+ | UDP-Lite| UDP| +-------------------+--------+-------------------+-------------+ | ヘッダー| サイズ| クラス| クラス| | 分野| (ビット) | | | +-------------------+--------+-------------------+-------------+ | ソース港| 16 | 静的にクールです。| 静的にクールです。| | 仕向港| 16 | 静的にクールです。| 静的にクールです。| | チェックサム適用範囲| 16 | 推論されます。| | | | | 静電気| | | | | 変化します。| | | 長さ| 16 | | 推論されます。| | チェックサム| 16 | 変化します。| 変化します。| +-------------------+--------+-------------------+-------------+
Source and Destination Port
ソースと仕向港
Same as for UDP. Specifically, these fields are part of the
definition of a stream and must thus be constant for all packets in
the stream. The fields are therefore classified as STATIC-DEF.
UDPのように、同じです。 明確に、これらの分野は、流れの定義の一部であり、すべてのパケットには、その結果、流れで一定でなければなりません。 したがって、分野はSTATIC-DEFとして分類されます。
Checksum Coverage
チェックサム適用範囲
This field specifies which part of the UDP-Lite datagram is covered
by the checksum. It may have a value of zero or be equal to the
datagram length if the checksum covers the entire datagram, or it
may have any value between eight octets and the length of the
datagram to specify the number of octets protected by the checksum,
この分野は、UDP-Liteデータグラムのどの部分がチェックサムで覆われているかを指定します。 8つの八重奏の間にどんな値も持っているかもしれません、そして、チェックサムが全体のデータグラムを覆うなら、ゼロの値を持っているか、データグラムの長さに堪えるかもしれません、または八重奏の数を指定するデータグラムの長さはチェックサムによって保護されました。
Pelletier Standards Track [Page 17] RFC 4019 ROHC: Profiles for UDP-Lite April 2005
ペレティアStandardsはRFC4019ROHCを追跡します[17ページ]: UDP-Liteのために、2005年4月の輪郭を描きます。
calculated from the first octet of the UDP-Lite header. The value
of this field may vary for each packet, and this makes the value
unpredictable from a header-compression perspective.
UDP-Liteヘッダーの最初の八重奏から、計算されています。 この分野の値は各パケットのために異なるかもしれません、そして、これで、値はヘッダー圧縮見解から予測できるようになりません。
Checksum
チェックサム
The information used for the calculation of the UDP-Lite checksum
is governed by the value of the checksum coverage and minimally
includes the UDP-Lite header. The checksum is a changing field
that must always be sent as-is.
UDP-Liteチェックサムの計算に使用される情報は、チェックサム適用範囲の値によって治められて、UDP-Liteヘッダーを最少量で含んでいます。 チェックサムはいつもそのままで送らなければならない変化野原です。
The total size of the fields in each class, for each expected change pattern (see section 3.2), is summarized in the tables below:
それぞれの予想された変化パターン(セクション3.2を見る)のために、各クラスにおける、分野の総サイズは以下のテーブルにまとめられます:
Pattern 1:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| INFERRED | 2 | Checksum Coverage
| STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 2 | Checksum
+------------+---------------+
パターン1: +------------+---------------+ | クラス| サイズ(八重奏)| +------------+---------------+ | 推論されます。| 2 | チェックサム適用範囲| 静的にクールです。| 4 | ソースポート/仕向港| 変化します。| 2 | チェックサム+------------+---------------+
Pattern 2:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| STATIC-DEF | 4 | Source Port / Destination Port
| STATIC | 2 | Checksum Coverage
| CHANGING | 2 | Checksum
+------------+---------------+
パターン2: +------------+---------------+ | クラス| サイズ(八重奏)| +------------+---------------+ | 静的にクールです。| 4 | ソースポート/仕向港| 静電気| 2 | チェックサム適用範囲| 変化します。| 2 | チェックサム+------------+---------------+
Pattern 3:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 4 | Checksum Coverage / Checksum
+------------+---------------+
パターン3: +------------+---------------+ | クラス| サイズ(八重奏)| +------------+---------------+ | 静的にクールです。| 4 | ソースポート/仕向港| 変化します。| 4 | チェックサム適用範囲/チェックサム+------------+---------------+
Pelletier Standards Track [Page 18] RFC 4019 ROHC: Profiles for UDP-Lite April 2005
ペレティアStandardsはRFC4019ROHCを追跡します[18ページ]: UDP-Liteのために、2005年4月の輪郭を描きます。
A.2. Header Compression Strategies for UDP-Lite
A.2。 UDP-Liteのためのヘッダー圧縮戦略
The following table revisits the corresponding table (table A.1) for UDP from [2] (section A.2) and classifies the changing fields based on the change patterns previously identified in section 3.2.
以下のテーブルは、UDPのために、[2](セクションA.2)から対応するテーブル(テーブルA.1)を再訪させて、変化パターンに基づいた分野が以前にセクション3.2で特定した変化を分類します。
Header compression strategies for UDP-Lite: +----------+---------+-------------+-----------+-----------+ | Field | Pattern | Value/Delta | Class | Knowledge | +==========+=========+=============+===========+===========+ | | #1 | Value | CHANGING | INFERRED | | Checksum |---------+-------------+-----------+-----------+ | Coverage | #2 | Value | RC | UNKNOWN | | |---------+-------------+-----------+-----------+ | | #3 | Value | IRREGULAR | UNKNOWN | +----------+---------+-------------+-----------+-----------+ | Checksum | All | Value | IRREGULAR | UNKNOWN | +----------+---------+-------------+-----------+-----------+
UDP-Liteのためのヘッダー圧縮戦略: +----------+---------+-------------+-----------+-----------+ | 分野| パターン| 値/デルタ| クラス| 知識| +==========+=========+=============+===========+===========+ | | #1 | 値| 変化します。| 推論されます。| | チェックサム|---------+-------------+-----------+-----------+ | 適用範囲| #2 | 値| RC| 未知| | |---------+-------------+-----------+-----------+ | | #3 | 値| 不規則| 未知| +----------+---------+-------------+-----------+-----------+ | チェックサム| すべて| 値| 不規則| 未知| +----------+---------+-------------+-----------+-----------+
A.2.1. Transmit initially but be prepared to update
A.2.1。 初めは、伝わってくださいが、用意していて、アップデートしてください。
UDP-Lite Checksum Coverage (Patterns #1 and #2)
UDP-Liteチェックサム適用範囲(パターン#1、と#2)
A.2.2. Transmit as-is in all packets
A.2.2。 すべてのパケットをそのままで伝わってください。
UDP-Lite Checksum UDP-Lite Checksum Coverage (Pattern #3)
UDP-LiteチェックサムUDP-Liteチェックサム適用範囲(パターン#3)
Pelletier Standards Track [Page 19] RFC 4019 ROHC: Profiles for UDP-Lite April 2005
ペレティアStandardsはRFC4019ROHCを追跡します[19ページ]: UDP-Liteのために、2005年4月の輪郭を描きます。
Appendix B. Detailed Format of the CCE Packet Type
CCEパケットタイプの付録のB.の詳細な形式
This section provides an expanded view of the format of the CCE packet, based on the general ROHC RTP compressed header [2] and the general format of a compressed header of the ROHC IP-Only profile [3]. The modifications necessary to carry the base header of a packet of type 2, 1 or 0 [2] within the CCE packet format, along with the additional fields to properly handle compression of multiple IP headers, result in the following structure for the CCE packet type:
このセクションはROHC IPだけプロフィール[3]の圧縮されたヘッダーの圧縮されたヘッダー[2]と一般形式を一般的なROHC RTPに基づいたCCEパケットの形式の拡張視点に提供します。 CCEパケット・フォーマットの中でタイプ2、1または0[2]のパケットのベースヘッダーを運ぶのに必要な変更は適切に複数のIPヘッダーの圧縮を扱う追加分野と共にCCEパケットタイプのための以下の構造をもたらします:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : If for small CIDs and CID 1 - 15
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 F | K | Outer packet type identifier
+---+---+---+---+---+---+---+---+
: :
/ 0, 1, or 2 octets of CID / 1 - 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
| First octet of base header | (with "inner" type indication)
+---+---+---+---+---+---+---+---+
/ Remainder of base header / Variable number of bits
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 --- --- --- --- --- --- --- --- : CIDを加えている八重奏: 小さいCIDsとCID1--15+のために---+---+---+---+---+---+---+---+ | 1 1 1 1 1 0F| K| 外側のパケットタイプ識別子+---+---+---+---+---+---+---+---+ : : CID/1--2つの八重奏の/0、1、または2八重奏、大きいCIDsであるなら: : +---+---+---+---+---+---+---+---+ | ベースヘッダーの最初の八重奏| (「内側」のタイプ指示がある) +---+---+---+---+---+---+---+---ベースヘッダー/可変な数のビット+の+/残り---+---+---+---+---+---+---+---+
Pelletier Standards Track [Page 20] RFC 4019 ROHC: Profiles for UDP-Lite April 2005
ペレティアStandardsはRFC4019ROHCを追跡します[20ページ]: UDP-Liteのために、2005年4月の輪郭を描きます。
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: :
/ Extension / See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
: :
+ IP-ID of outer IPv4 header + See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
/ AH data for outer list / See RFC 3095 [2], section 5.7.
--- --- --- --- --- --- --- ---
: :
+ GRE checksum + See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
: :
+ IP-ID of inner IPv4 header + See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
/ AH data for inner list / See RFC 3095 [2], section 5.7.
--- --- --- --- --- --- --- ---
: :
+ GRE checksum + See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
: List of : Variable, given by static chain
/ dynamic chains / (includes no SN).
: for additional IP headers : See [3], section 3.2.
--- --- --- --- --- --- --- ---
: :
+ UDP-Lite Checksum Coverage + 2 octets
: :
+---+---+---+---+---+---+---+---+
: :
+ UDP-Lite Checksum + 2 octets
: :
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 --- --- --- --- --- --- --- --- : : /拡大/はRFC3095[2]、セクション5.7を見ます。 : : --- --- --- --- --- --- --- --- : : + +が見る外側のIPv4ヘッダーのIP-ID RFC3095[2]、セクション5.7。 : : --- --- --- --- --- --- --- --- 外側のリスト/のための/AHデータはRFC3095[2]、セクション5.7を見ます。 --- --- --- --- --- --- --- --- : : + GREチェックサム+はRFC3095[2]、セクション5.7を見ます。 : : --- --- --- --- --- --- --- --- : : + +が見る内側のIPv4ヘッダーのIP-ID RFC3095[2]、セクション5.7。 : : --- --- --- --- --- --- --- --- 内側のリスト/のための/AHデータはRFC3095[2]、セクション5.7を見ます。 --- --- --- --- --- --- --- --- : : + GREチェックサム+はRFC3095[2]、セクション5.7を見ます。 : : --- --- --- --- --- --- --- --- : 以下のリスト 静的なチェーン/ダイナミックなチェーン/(SNを全く含んでいません)によって与えられた変数。 : 追加IPヘッダーのために: [3]、セクション3.2を見てください。 --- --- --- --- --- --- --- --- : : + UDP-Lite Checksum Coverage+2つの八重奏: : +---+---+---+---+---+---+---+---+ : : + UDP-Lite Checksum+2つの八重奏: : +---+---+---+---+---+---+---+---+
F,K: F,K = 00 is reserved at framework level (IR-DYN);
F,K = 01 indicates CCE();
F,K = 10 indicates CCE(ON);
F,K = 11 indicates CCE(OFF).
F、K: F、K=00は枠組みのレベル(IR-DYN)で予約されます。 F、K=01はCCE()を示します。 F、K=10はCCE(ON)を示します。 F、K=11はCCE(OFF)を示します。
Note that this document does not define (F,K) = 00, as this would collide with the IR-DYN packet type already reserved at the ROHC framework level.
このドキュメントが(F、K)=00を定義しないことに注意してください、これがROHC枠組みのレベルで既に予約されるIR-DYNパケットタイプに衝突するだろうというとき。
Pelletier Standards Track [Page 21] RFC 4019 ROHC: Profiles for UDP-Lite April 2005
ペレティアStandardsはRFC4019ROHCを追跡します[21ページ]: UDP-Liteのために、2005年4月の輪郭を描きます。
Author's Address
作者のアドレス
Ghyslain Pelletier Ericsson AB Box 920 SE-971 28 Lulea, Sweden
GhyslainペレティアエリクソンAB箱920のSE-971 28ルーレオ(スウェーデン)
Phone: +46 840 429 43 Fax : +46 920 996 21 EMail: ghyslain.pelletier@ericsson.com
以下に電話をしてください。 +46 840 429 43ファックス: +46 920 996 21メール: ghyslain.pelletier@ericsson.com
Pelletier Standards Track [Page 22] RFC 4019 ROHC: Profiles for UDP-Lite April 2005
ペレティアStandardsはRFC4019ROHCを追跡します[22ページ]: UDP-Liteのために、2005年4月の輪郭を描きます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Pelletier Standards Track [Page 23]
ペレティア標準化過程[23ページ]
一覧
スポンサーリンク
