RFC2507 日本語訳
2507 IP Header Compression. M. Degermark, B. Nordgren, S. Pink. February 1999. (Format: TXT=106292 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Degermark
Request for Comments: 2507 Lulea University of Technology/SICS
Category: Standards Track B. Nordgren
Lulea University of Technology/Telia Research AB
S. Pink
Lulea University of Technology/SICS
February 1999
コメントを求めるワーキンググループM.デーゲルマルク要求をネットワークでつないでください: 2507年の技術/のルーレオ大学はカテゴリを攻撃します: 技術/の技術/冬胞子堆の研究のABのS.のピンクのルーレオ大学の標準化過程B.Nordgrenルーレオ大学は1999年2月に攻撃されます。
IP Header Compression
IPヘッダー圧縮
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
This document describes how to compress multiple IP headers and TCP and UDP headers per hop over point to point links. The methods can be applied to of IPv6 base and extension headers, IPv4 headers, TCP and UDP headers, and encapsulated IPv6 and IPv4 headers.
このドキュメントはリンクを指すために1ホップあたりの複数のIPヘッダー、TCP、およびUDPヘッダーをポイントの上に圧縮する方法を説明します。 メソッドをIPv6ベース、拡張ヘッダー、IPv4ヘッダー、TCP、およびUDPヘッダーに適用して、IPv6とIPv4ヘッダーであるとカプセル化することができます。
Headers of typical UDP or TCP packets can be compressed down to 4-7 octets including the 2 octet UDP or TCP checksum. This largely removes the negative impact of large IP headers and allows efficient use of bandwidth on low and medium speed links.
典型的なUDPかTCPパケットのヘッダーを4-7 2八重奏UDPかTCPチェックサムを含む八重奏まで圧縮できます。 これは、大きいIPヘッダーの負の衝撃を主に取り除いて、低くて中型の速度リンクにおける帯域幅の効率的な使用を許します。
The compression algorithms are specifically designed to work well over links with nontrivial packet-loss rates. Several wireless and modem technologies result in such links.
圧縮アルゴリズムは、重要なパケット損失率とのリンクの上にうまくいくように明確に設計されています。 いくつかのワイヤレスとモデム技術がそのようなリンクをもたらします。
TABLE OF CONTENTS
目次
1. Introduction..............................................3
2. Terminology...............................................5
3. Compression method........................................7
3.1. Packet types.......................................8
3.2. Lost packets in TCP packet streams.................9
3.3. Lost packets in UDP and non-TCP packet streams....10
4. Grouping packets into packet streams.....................14
1. 序論…3 2. 用語…5 3. 圧縮メソッド…7 3.1. パケットはタイプされます…8 3.2. TCPパケットストリームでパケットを失います…9 3.3. UDPの無くなっているパケットと非TCPパケットは流れます…10 4. パケットをパケットに分類するのは流れます…14
Degermark, et. al. Standards Track [Page 1] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[1ページ]。
4.1. Guidelines for grouping packets...................15
5. Size Issues..............................................16
5.1. Context identifiers...............................16
5.2. Size of the context...............................17
5.3. Size of full headers..............................18
5.3.1. Length fields in full TCP headers............19
5.3.2. Length fields in full non-TCP headers........19
6. Compressed Header Formats................................20
7. Compression of subheaders................................22
7.1. IPv6 Header.......................................24
7.2. IPv6 Extension Headers............................25
7.3. Options...........................................25
7.4. Hop-by-hop Options Header.........................26
7.5. Routing Header....................................26
7.6. Fragment Header...................................27
7.7. Destination Options Header........................28
7.8. No Next Header....................................29
7.9. Authentication Header.............................29
7.10. Encapsulating Security Payload Header.............29
7.11. UDP Header........................................30
7.12. TCP Header........................................30
7.13. IPv4 Header.......................................33
7.14 Minimal Encapsulation header......................34
8. Changing context identifiers.............................35
9. Rules for dropping or temporarily storing packets........35
10. Low-loss header compression for TCP .....................36
10.1. The "twice" algorithm............................37
10.2. Header Requests..................................37
11. Links that reorder packets...............................38
11.1. Reordering in non-TCP packet streams.............39
11.2. Reordering in TCP packet streams.................39
12. Hooks for additional header compression..................40
13. Demultiplexing...........................................41
14. Configuration Parameters.................................42
15. Implementation Status....................................43
16. Acknowledgments..........................................44
17. Security Considerations..................................44
18. Authors' Addresses.......................................45
19. References...............................................46
20. Full Copyright Statement.................................47
4.1. パケットを分類するためのガイドライン…15 5. サイズ問題…16 5.1. 文脈識別子…16 5.2. 文脈のサイズ…17 5.3. 完全なヘッダーのサイズ…18 5.3.1. 長さは完全なTCPでヘッダーをさばきます…19 5.3.2. 完全な非TCPヘッダーの長さの分野…19 6. ヘッダー形式を圧縮します…20 7. 「副-ヘッダー」の圧縮…22 7.1. IPv6ヘッダー…24 7.2. IPv6拡張ヘッダー…25 7.3. オプション…25 7.4. ホップごとのオプションヘッダー…26 7.5. ルート設定ヘッダー…26 7.6. ヘッダーを断片化してください…27 7.7. 目的地オプションヘッダー…28 7.8. いいえ、次のヘッダー…29 7.9. 認証ヘッダー…29 7.10. セキュリティ有効搭載量がヘッダーであるとカプセル化します…29 7.11. UDPヘッダー…30 7.12. TCPヘッダー…30 7.13. IPv4ヘッダー…33 7.14の最小量のEncapsulationヘッダー…34 8. 文脈識別子を変えます…35 9. パケットを下げるか、または一時保存するための規則…35 10. TCPのための低い損失ヘッダー圧縮…36 10.1. 「二度」というアルゴリズム…37 10.2. ヘッダー要求…37 11. その追加注文パケットをリンクします…38 11.1. 非TCPパケットでReorderingするのは流れます…39 11.2. TCPパケットでReorderingするのは流れます…39 12. 追加ヘッダー圧縮のために、フックします…40 13. 逆多重化…41 14. 構成パラメタ…42 15. 実装状態…43 16. 承認…44 17. セキュリティ問題…44 18. 作者のアドレス…45 19. 参照…46 20. 完全な著作権宣言文…47
Degermark, et. al. Standards Track [Page 2] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[2ページ]。
1. Introduction
1. 序論
There are several reasons to do header compression on low- or medium-speed links. Header compression can
安値かミディアム・スピードにおけるヘッダー圧縮にリンクをするいくつかの理由があります。 ヘッダー圧縮はそうすることができます。
* Improve interactive response time
* 対話的な応答時間を改良してください。
For very low-speed links, echoing of characters may take longer
than 100-200 ms because of the time required to transmit large
headers. 100-200 ms is the maximum time people can tolerate
without feeling that the system is sluggish.
非常に低速なリンクに、キャラクタの反響は100-200 時間によるmsが大きいヘッダーを伝えるのが必要であるより長い間、かかるかもしれません。 100-200msはシステムが停滞していると感じない人々が許容できる最大の時間です。
* Allow using small packets for bulk data with good line efficiency
* 大量のデータに良い系列効率で小型小包を使用させてください。
This is important when interactive (for example Telnet) and bulk
traffic (for example FTP) is mixed because the bulk data should be
carried in small packets to decrease the waiting time when a
packet with interactive data is caught behind a bulk data packet.
大量のデータが対話的なデータがあるパケットが大量のデータ・パケットの後ろに捕らえられるとき、待ち時間を減少させるために小型小包で運ばれるべきであるのでインタラクティブ(例えば、Telnet)と大量のトラフィック(例えば、FTP)が複雑であるときに、これは重要です。
Using small packet sizes for the FTP traffic in this case is a
global solution to a local problem. It will increase the load on
the network as it has to deal with many small packets. A better
solution might be to locally fragment the large packets over the
slow link.
この場合FTPトラフィックに小型小包サイズを使用するのは、ローカルの問題へのグローバルな解決です。 多くの小型小包に対処しなければならないのに従って、それはネットワークで負荷を増強するでしょう。 より良いソリューションは遅いリンクの上に局所的に大きいパケットを断片化することであるかもしれません。
* Allow using small packets for delay sensitive low data-rate traffic
* 遅れの敏感な低いデータ信号速度トラフィックに小型小包を使用させてください。
For such applications, for example voice, the time to fill a
packet with data is significant if packets are large. To get low
end-to-end delay small packets are preferred. Without header
compression, the smallest possible IPv6/UDP headers (48 octets)
consume 19.2 kbit/s with a packet rate of 50 packets/s. 50
packets/s is equivalent to having 20 ms worth of voice samples in
each packet. IPv4/UDP headers consumes 11.2 kbit/s at 50
packets/s. Tunneling or routing headers, for example to support
mobility, will increase the bandwidth consumed by headers by 10-20
kbit/s. This should be compared with the bandwidth required for
the actual sound samples, for example 13 kbit/s with GSM encoding.
Header compression can reduce the bandwidth needed for headers
significantly, in the example to about 1.7 kbit/s. This enables
higher quality voice transmission over 14.4 and 28.8 kbit/s
modems.
そのようなアプリケーション、例えば、声において、パケットが大きいなら、データでパケットを満たす時間は重要です。 低端から端への遅れを得るために、小型小包は好まれます。 ヘッダー圧縮がなければ、可能な限り小さいIPv6/UDPヘッダー(48の八重奏)は50パケット/sのパケットレートで19.2kbit/sを消費します。 50パケット/sは20msを持っているのに声のサンプルの各パケットにおいて価値があった状態で同等です。 IPv4/UDPヘッダーは50パケット/sで11.2kbit/sを消費します。 トンネリングかルーティングヘッダーが、例えば移動性をサポートするために10-20 kbit/sによってヘッダーによって消費された帯域幅を増強するでしょう。 これは実際の音のサンプル、例えば、GSMコード化がある13kbit/sに必要である帯域幅と比較されるべきです。 ヘッダー圧縮は例でヘッダーにかなり必要である帯域幅をおよそ1.7kbit/sに減少させることができます。 これは、より高い上質の音声伝送より多くの14.4と28.8個のkbit/sモデムを可能にします。
* Decrease header overhead.
* ヘッダーオーバーヘッドを下げてください。
A common size of TCP segments for bulk transfers over medium-speed
links is 512 octets today. When TCP segments are tunneled, for
example because Mobile IP is used, the IPv6/IPv6/TCP header is 100
今日、ミディアム・スピードの上バルク転送リンクへのTCPセグメントの一般的なサイズは512の八重奏です。 例えば、モバイルIPが使用されているのでTCPセグメントがトンネルを堀られるとき、IPv6/IPv6/TCPヘッダーは100歳です。
Degermark, et. al. Standards Track [Page 3] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[3ページ]。
octets. Header compression will decrease the header overhead for
IPv6/TCP from 19.5 per cent to less than 1 per cent, and for
tunneled IPv4/TCP from 11.7 to less than 1 per cent. This is a
significant gain for line-speeds as high as a few Mbit/s.
八重奏。 ヘッダー圧縮は19.5パーセントから1パーセント未満までのIPv6/TCP、およびトンネルを堀られた11.7〜1パーセント未満までのIPv4/TCPのためにヘッダーオーバーヘッドを下げるでしょう。 これはいくつかとしての高同じくらいライン・スピードメガビット/sのための重要な利得です。
The IPv6 specification prescribes path MTU discovery, so with IPv6
bulk TCP transfers should use segments larger than 512 octets when
possible. Still, with 1400 octet segments (RFC 894 Ethernet
encapsulation allows 1500 octet payloads, of which 100 octets are
used for IP headers), header compression reduces IPv6 header
overhead from 7.1% to 0.4%.
IPv6仕様が経路MTU探索を定めるので、可能であるときに、IPv6嵩と共に、TCP転送は512の八重奏より大きいセグメントを使用するべきです。 それでも、1400の八重奏セグメント(RFC894イーサネットカプセル化は1500個の八重奏ペイロードを許容する)で、ヘッダー圧縮はIPv6ヘッダーオーバーヘッドを7.1%から0.4%まで下げます。そこでは、100の八重奏がIPヘッダーに使用されます。
* Reduce packet loss rate over lossy links.
* 損失性リンクの上にパケット損失率を低下させてください。
Because fewer bits are sent per packet, the packet loss rate will
be lower for a given bit-error rate. This results in higher
throughput for TCP as the sending window can open up more between
losses, and in fewer lost packets for UDP.
パケット単位で、より少ないビットを送るので、パケット損失率は与えられたビット誤り率のために低いでしょう。 送付の窓がさらに損失の間と、そして、UDPには、より少ない無くなっているパケットで開くことができるとき、これはTCPには、より高いスループットをもたらします。
The mechanisms described here are intended for a point-to-point link. However, care has been taken to allow extensions for multi-access links and multicast.
ここで説明されたメカニズムはポイントツーポイント接続に意図します。 しかしながら、マルチアクセスリンクのための拡大とマルチキャストを許容するために、注意しました。
Headers that can be compressed include TCP, UDP, IPv4, and IPv6 base and extension headers. For TCP packets, the mechanisms of Van Jacobson [RFC-1144] are used to recover from loss. Two additional mechanisms that increase the efficiency of VJ header compression over lossy links are also described. For non-TCP packets, compression slow-start and periodic header refreshes allow minimal periods of packet discard after loss of a header that changes the context. There are hooks for adding header compression schemes on top of UDP, for example compression of RTP headers.
圧縮できるヘッダーはTCP、UDP、IPv4、IPv6ベース、および拡張ヘッダーを入れます。 TCPパケットに関しては、ヴァン・ジェーコブソン[RFC-1144]のメカニズムは、損失から回復するのに使用されます。 また、損失性リンクの上にVJヘッダー圧縮の効率を増強する2つの追加メカニズムが説明されます。 非TCPパケット、遅い始めの、そして、周期的なヘッダーがリフレッシュする圧縮には、文脈を変えるヘッダーの損失の後に最小量の期間のパケット破棄を許してください。 UDPの上でヘッダー圧縮技術を加えるためのフック、例えばRTPヘッダーの圧縮があります。
Header compression relies on many fields being constant or changing seldomly in consecutive packets belonging to the same packet stream. Fields that do not change between packets need not be transmitted at all. Fields that change often with small and/or predictable values, e.g., TCP sequence numbers, can be encoded incrementally so that the number of bits needed for these fields decrease significantly. Only fields that change often and randomly, e.g., checksums or authentication data, need to be transmitted in every header.
ヘッダー圧縮は、同じパケットストリームに属しながら、連続したパケットでめったに多くの一定の分野か変化を当てにします。 パケットの間で変化しない野原は全く伝えられる必要はありません。 しばしば小さい、そして/または、予測できる値を交換する分野(例えば、TCP一連番号)は増加してコード化できるので、これらの分野に必要であるビットの数はかなり減少します。 しばしば、手当たりしだいに変化する分野(例えば、チェックサムか認証データ)だけが、すべてのヘッダーで伝えられる必要があります。
The general principle of header compression is to occasionally send a packet with a full header; subsequent compressed headers refer to the context established by the full header and may contain incremental changes to the context.
ヘッダー圧縮の一般的な原則は完全なヘッダーと共にパケットを時折送ることです。 その後の圧縮されたヘッダーは、完全なヘッダーによって確立された文脈を示して、文脈への漸進的変化を含むかもしれません。
Degermark, et. al. Standards Track [Page 4] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[4ページ]。
This header compression scheme does not require that all packets in the same stream passes over the compressed link. However, for TCP streams the difference between subsequent headers can become more irregular and the compression rate can decrease. Neither is it required that corresponding TCP data and acknowledgment packets traverse the link in opposite directions.
このヘッダー圧縮技術は、同じくらいのパケットが流すすべてが圧縮されたリンクを通り過ぎるのを必要としません。 しかしながら、TCPストリームのために、その後のヘッダーの違いは、より不規則になることができます、そして、圧縮率は減少できます。 どちらも対応するTCPデータと確認応答パケットがそれぞれ反対の方向にリンクを横断するのが必要であったということではありません。
This header compression scheme is useful on first-hop or last-hop links as well as links in the middle of the network. When many packet streams (several hundred) traverse the link, a phenomenon that could be called CID thrashing could occur, where headers seldom can be matched with an existing context and have to be sent uncompressed or as full headers. It is up to an implementation to use techniques such as hysteresis to ensure that the packet streams that give the highest compression rates keep their context. Such techniques are more likely to be needed in the middle of the network.
このヘッダー圧縮技術はネットワークの中央のリンクと同様に最初に、ホップか最後のホップリンクで役に立ちます。 多くのパケットストリーム(数100)がリンクを横断するとき、CIDの打つと呼ぶことができた現象は起こることができました、ヘッダーをめったに既存の文脈に合わせることができないで、解凍されたか完全なヘッダーに送らなければならないところで。 最も高い圧縮率を与えるパケットストリームがそれらの文脈を保つのを保証するのにヒステリシスなどのテクニックを使用するのは実装まで達しています。 ネットワークの中央では、そのようなテクニックが、より必要でありそうです。
2. Terminology
2. 用語
This section explains some terms used in this document.
このセクションは本書では使用されるいくつかの用語について説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
Subheader
Subheader
An IPv6 base header, an IPv6 extension header, an IPv4 header, a
UDP header, or a TCP header.
IPv6ベースヘッダー、IPv6拡張ヘッダー、IPv4ヘッダー、UDPヘッダー、またはTCPヘッダー。
Header
ヘッダー
A chain of subheaders.
「副-ヘッダー」のチェーン。
Compress
湿布
The act of reducing the size of a header by removing header fields
or reducing the size of header fields. This is done in a way such
that a decompressor can reconstruct the header if its context
state is identical to the context state used when compressing the
header.
ヘッダーフィールドを取り除くことによってヘッダーのサイズを減少させるか、またはヘッダーフィールドのサイズを減少させる行為。 文脈状態がヘッダーを圧縮するとき使用される文脈状態と同じであるなら減圧装置がヘッダーを再建できるように、方法でこれをします。
Decompress
減圧してください。
The act of reconstructing a compressed header.
圧縮されたヘッダーを再建する行為。
Degermark, et. al. Standards Track [Page 5] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[5ページ]。
Context identifier (CID)
文脈識別子(Cid)
A small unique number identifying the context that should be used
to decompress a compressed header. Carried in full headers and
compressed headers.
圧縮されたヘッダーを減圧するのに使用されるべきである文脈を特定する少ないユニークな数。 完全なヘッダーと圧縮されたヘッダーでは、運ばれます。
Context
文脈
The state which the compressor uses to compress a header and the
decompressor uses to decompress a header. The context is the
uncompressed version of the last header sent (compressor) or
received (decompressor) over the link, except for fields in the
header that are included "as-is" in compressed headers or can be
inferred from, e.g., the size of the link-level frame.
コンプレッサーがヘッダーを圧縮するのに使用して、減圧装置がヘッダーを減圧するのに使用する状態。 文脈はヘッダーをヘッダーの圧縮されたヘッダーに「そのままで」含まれている分野以外のリンクの上に送るか(コンプレッサー)、受ける(減圧装置)、または推論できる最終解凍されたバージョンです、例えば、リンク・レベルフレームのサイズ。
The context for a packet stream is associated with a context
identifier. The context for non-TCP packet streams is also
associated with a generation.
パケットストリームのための文脈は文脈識別子に関連しています。 また、非TCPパケットストリームのための文脈も1世代に関連しています。
Generation
世代
For non-TCP packet streams, each new version of the context for a
given CID is associated with a generation: a small number that is
incremented whenever the context associated with that CID changes.
Carried by full and compressed non-TCP headers.
非TCPパケットストリームにおいて、与えられたCIDのための文脈のそれぞれの新しいバージョンは1世代に関連しています: そのCIDに関連している文脈が変化するときはいつも、増加している少ない数。 完全で圧縮された非TCPヘッダーによって運ばれます。
Packet stream
パケットストリーム
A sequence of packets whose headers are similar and share context.
For example, headers in a TCP packet stream have the same source
and final destination address, and the same port numbers in the
TCP header. Similarly, headers in a UDP packet stream have the
same source and destination address, and the same port numbers in
the UDP header.
ヘッダーが同様であり、文脈を共有するパケットの系列。 例えば、TCPパケットストリームにおけるヘッダーはTCPヘッダーに同じソース、最終的な送付先アドレス、および同じポートナンバーを持っています。 同様に、UDPパケットストリームにおけるヘッダーはUDPヘッダーに同じソース、送付先アドレス、および同じポートナンバーを持っています。
Full header (header refresh)
完全なヘッダー(ヘッダーはリフレッシュします)
An uncompressed header that updates or refreshes the context for a
packet stream. It carries a CID that will be used to identify the
context.
パケットストリームのための文脈をアップデートするか、またはリフレッシュする解凍されたヘッダー。 それは文脈を特定するのに使用されるCIDを運びます。
Full headers for non-TCP packet streams also carry the generation
of the context they update or refresh.
非TCPパケットストリームのための完全なヘッダーは、また、それらがアップデートする文脈の世代を運ぶか、またはリフレッシュします。
Regular header
レギュラーのヘッダー
A normal, uncompressed, header. Does not carry CID or generation
association.
正常で、解凍されたヘッダー。 CIDか世代協会を運びません。
Degermark, et. al. Standards Track [Page 6] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[6ページ]。
Incorrect decompression
不正確な減圧
When a compressed and then decompressed header is different from
the uncompressed header. Usually due to mismatching context
between the compressor and decompressor or bit errors during
transmission of the compressed header.
圧縮されて次に、減圧されたヘッダーが解凍されたヘッダーと異なっているとき。 通常、圧縮されたヘッダーのトランスミッションの間、コンプレッサーと減圧装置か噛み付いている誤りの間の文脈にミスマッチするため。
Differential coding
差分符号化
A compression technique where the compressed value of a header
field is the difference between the current value of the field and
the value of the same field in the previous header belonging to
the same packet stream. A decompressor can thus obtain the value
of the field by adding the value in the compressed header to its
context. This technique is used for TCP streams but not for non-
TCP streams.
ヘッダーフィールドの圧縮された値が同じパケットストリームに属す前のヘッダーの分野の現行価値と同じ分野の値の違いである圧縮のテクニック。 その結果、減圧装置は、圧縮されたヘッダーで価値を文脈に高めることによって、分野の値を得ることができます。 このテクニックは、TCPストリームに使用されますが、非TCPのストリームに使用されるというわけではありません。
3. Compression method
3. 圧縮方法
Much of the header information stays the same over the life-time of a packet stream. For non-TCP packet streams almost all fields of the headers are constant. For TCP many fields are constant and others change with small and predictable values.
ヘッダー情報の多くがパケットストリームの生涯同じ状態で残っています。 非TCPパケットストリームにおいて、ヘッダーのほとんどすべての分野が一定です。 TCPに関しては、多くの分野が一定です、そして、他のものは小さくて予測できる値を交換します。
To initiate compression of the headers of a packet stream, a full header carrying a context identifier, CID, is transmitted over the link. The compressor and decompressor store most fields of this full header as context. The context consists of the fields of the header whose values are constant and thus need not be sent over the link at all, or change little between consecutive headers so that it uses fewer bits to send the difference from the previous value compared to sending the absolute value.
パケットストリームのヘッダーの圧縮を開始するために、文脈識別子を運ぶ完全なヘッダー(CID)はリンクの上に伝えられます。 コンプレッサーと減圧装置は文脈としてこの完全なヘッダーのほとんどの分野を保存します。 その結果、文脈が値が一定であるヘッダーの分野から成って、リンクの上に全く送る必要はありませんし、また連続したヘッダーの間で少なく変化する必要はないので、それは絶対値を送ると比べて、前の値から違いを送るのにより少ないビットを使用します。
Any change in fields that are expected to be constant in a packet stream will cause the compressor to send a full header again to update the context at the decompressor. As long as the context is the same at compressor and decompressor, headers can be decompressed to be exactly as they were before compression. However, if a full header or compressed header is lost during transmission, the context of the decompressor may become obsolete as it is not updated properly. Compressed headers will then be decompressed incorrectly.
パケットストリームで一定であると予想される分野のどんな変化でも、コンプレッサーは、減圧装置で文脈をアップデートするために再び完全なヘッダーを送るでしょう。 関係がコンプレッサーと減圧装置で同じである限り、圧縮の前に、彼らがいて、まさにであるなるようにヘッダーを減圧できます。 しかしながら、完全なヘッダーか圧縮されたヘッダーがトランスミッションの間、なくされているなら、適切にそれをアップデートしないとき、減圧装置の文脈は時代遅れになるかもしれません。 そして、圧縮されたヘッダーは不当に減圧されるでしょう。
IPv6 is not meant to be used over links that can deliver a significant fraction of damaged packets to the IPv6 module. This means that links must have a very low bit-error rate or that link- level frames must be protected by strong checksums, forward error correction or something of that nature. Header compression SHOULD not be used for IPv4 without strong link-level checksums. Damaged
IPv6は破損しているパケットの重要な部分をIPv6モジュールに提供できるリンクの上に使用されることになっていません。 これは、リンクには非常に低いビット誤り率がなければならないか、またはその自然について強いチェックサム、前進型誤信号訂正または何かでリンクの平らなフレームを保護しなければならないことを意味します。 IPv4に強いリンク・レベルチェックサムなしで使用されないでください。ヘッダー圧縮SHOULD、破損しました。
Degermark, et. al. Standards Track [Page 7] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[7ページ]。
frames will thus be discarded by the link layer. The link layer implementation might indicate to the header compression module that a frame was damaged, but it cannot say what packet stream it belonged to as it might be the CID that is damaged. Moreover, frames may disappear without the link layer implementation's knowledge, for example if the link is a multi-hop link where frames can be dropped due to congestion at each hop. The kind of link errors that a header compression module should deal with and protect against will thus be packet loss.
その結果、フレームはリンクレイヤによって捨てられるでしょう。 リンクレイヤ実装は、フレームが破損したのをヘッダー圧縮モジュールに示すかもしれませんが、それは、破損しているCIDであるかもしれないのでどんなパケットストリームに属したかを示すことができません。 そのうえ、フレームはリンクレイヤ実装の知識なしで見えなくなるかもしれません、例えば、リンクが混雑のため各ホップでフレームを下げることができるマルチホップリンクであるなら。 その結果、ヘッダー圧縮モジュールが対処して、守るべきであるリンク誤りの種類はパケット損失になるでしょう。
So a header compression scheme needs mechanisms to update the context at the decompressor and to detect or avoid incorrect decompression. These mechanisms are very different for TCP and non-TCP streams, and are described in sections 3.2 and 3.3.
それで、ヘッダー圧縮技術は、不正確な減圧を減圧装置で文脈をアップデートして、検出するか、または避けるためにメカニズムを必要とします。 これらのメカニズムは、TCPと非TCPストリームにおいて非常に異なって、セクション3.2と3.3で説明されます。
The compression mechanisms in this document assume that packets are not reordered between the compressor and decompressor. If the link
圧縮機構は、パケットがコンプレッサーと減圧装置の間で再命令されないと本書では仮定します。 リンクです。
does reorder, section 11 describes mechanisms for ordering the packets before decompression. It is also assumed that the link-layer implementation can provide the length of packets, and that there is no padding in UDP packets or tunneled packets.
追加注文、11が減圧の前にパケットを注文しながらメカニズムについて説明するセクションをします。 また、リンクレイヤ実装がパケットの長さを提供できて、UDPパケットかトンネルを堀られたパケットでそっと歩いてはいけないと思われます。
3.1. Packet types
3.1. パケットタイプ
This compression method uses four packet types in addition to the IPv4 and IPv6 packet types. The combination of link-level packet type and the value of the first four bits of the packet uniquely determines the packet type. Details on how these packet types are represented are in section 13.
この圧縮方法はIPv4とIPv6パケットタイプに加えて4つのパケットタイプを使用します。 リンク・レベルパケットタイプの組み合わせとパケットの最初の4ビットの価値は唯一パケットタイプを決定します。 これらのパケットタイプがどう代理をされるかに関する詳細がセクション13にあります。
FULL_HEADER - indicates a packet with an uncompressed header,
including a CID and, if not a TCP packet, a generation. It
establishes or refreshes the context for the packet stream
identified by the CID.
FULL_HEADER--CIDとTCPパケットでないことの1世代を含む解凍されたヘッダーと共にパケットを示します。 それは、CIDによって特定されたパケットストリームのための文脈を確立するか、またはリフレッシュします。
COMPRESSED_NON_TCP - indicates a non-TCP packet with a compressed
header. The compressed header consists of a CID identifying what
context to use for decompression, a generation to detect an
inconsistent context and the randomly changing fields of the
header.
COMPRESSED_NON_TCP--圧縮されたヘッダーと共に非TCPパケットを示します。 圧縮されたヘッダーは減圧(ヘッダーの矛盾した関係と手当たりしだいに変化している分野を検出する世代)にどんな文脈を使用したらよいかを特定するCIDから成ります。
COMPRESSED_TCP - indicates a packet with a compressed TCP header,
containing a CID, a flag octet indentifying what fields have
changed, and the changed fields encoded as the difference from
the previous value.
COMPRESSED_TCP--CID、分野が変えたものをindentifyingする旗の八重奏、および違いとして前の値からコード化された変えられた分野を含んでいて、圧縮されたTCPヘッダーと共にパケットを示します。
Degermark, et. al. Standards Track [Page 8] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[8ページ]。
COMPRESSED_TCP_NODELTA - indicates a packet with a compressed TCP
header where all fields that are normally sent as the difference
to the previous value are instead sent as-is. This packet type
is only sent as the response to a header request from the
decompressor. It must not be sent as the result of a
retransmission.
COMPRESSED_TCP_NODELTA--通常、違いとして前の値に送られるすべての野原が代わりにそのままで送られる圧縮されたTCPヘッダーと共にパケットを示します。 ヘッダー要求への応答として減圧装置からこのパケットタイプを送るだけです。 「再-トランスミッション」の結果としてそれを送ってはいけません。
In addition to the packet types used for compression, regular IPv4 and IPv6 packets are used whenever a compressor decides to not compress a packet. An additional packet type may be used to speed up repair of TCP streams over links where the decompressor can send packets to the compressor.
圧縮に使用されるパケットタイプに加えて、コンプレッサーが、パケットを圧縮しないと決めるときはいつも、通常のIPv4とIPv6パケットは使用されています。 追加パケットタイプは、減圧装置がパケットをコンプレッサーに送ることができるリンクの上にTCPストリームの修理を早くするのに使用されるかもしれません。
CONTEXT_STATE - indicates a special packet sent from the
decompressor to the compressor to communicate a list of (TCP)
CIDs for which synchronization has been lost. This packet is only
sent over a single link so it requires no IP header. The format
is shown in section 10.2.
CONTEXT_州--特別なパケットが同期が失われた(TCP)CIDsのリストを伝えるために減圧装置からコンプレッサーまで発信したのを示します。 単一のリンクの上にこのパケットを送るだけであるので、それはIPヘッダーを全く必要としません。 書式はセクション10.2で示されます。
3.2. Lost packets in TCP packet streams
3.2. TCPパケットストリームにおける無くなっているパケット
Since TCP headers are compressed using the difference from the previous TCP header, loss of a packet with a compressed or full header will cause subsequent compressed headers to be decompressed incorrectly because the context used for decompression was not incremented properly.
TCPヘッダーが前のTCPヘッダーから違いを使用することで圧縮されるとき、減圧に使用される文脈が適切に増加されなかったので、圧縮されたか完全なヘッダーによるパケットの損失で、不当にその後の圧縮されたヘッダーを減圧するでしょう。
Loss of a compressed TCP header will cause the TCP sequence numbers of subsequently decompressed TCP headers to be off by k, where k is the size of the lost segment. Such incorrectly decompressed TCP headers will be discarded by the TCP receiver as the TCP checksum reliably catches "off-by-k" errors in the sequence numbers for plausible k.
圧縮されたTCPヘッダーの損失は、kで次に減圧されたTCPヘッダーのTCP一連番号がオフであることを引き起こすでしょう。そこでは、kが無くなっているセグメントのサイズです。 TCPチェックサムが確かに捕らえるような捨てられて、ヘッダーがTCP受信機で望んでいる不当に減圧されたTCP、「オフである、k、」 もっともらしいkのための一連番号における誤り。
TCP's repair mechanisms will eventually retransmit the discarded segment and the compressor peeks into the TCP headers to detect when TCP retransmits. When this happens, the compressor sends a full header on the assumption that the retransmission was due to mismatching compression state at the decompressor. [RFC-1144] has a good explanation of this mechanism.
TCPの修理メカニズムは結局捨てられたセグメントを再送するでしょう、そして、コンプレッサーは、TCPがいつ再送するかを検出するためにTCPヘッダーを覗き見されます。 これが起こると、コンプレッサーは「再-トランスミッション」が減圧装置で圧縮状態にミスマッチするためであったという前提での完全なヘッダーを送ります。 [RFC-1144]には、このメカニズムの良い説明があります。
The mechanisms of section 10 should be used to speed up the repair of the context. This is important over medium speed links with high packet loss rates, for example wireless. Losing a timeout's worth of packets due to inconsistent context after each packet lost over the link is not acceptable, especially when the TCP connection is over the wide area.
セクション10のメカニズムは、文脈の修理を早くするのに使用されるべきです。 これは、高いパケット損失率とのミディアム・スピードリンクの上に重要であって、例えば、ワイヤレスです。 矛盾した関係のため各パケットがリンクの上に損をした後にタイムアウトのパケットの価値を失うのは許容できません、特に広い領域にわたってTCP接続があるとき。
Degermark, et. al. Standards Track [Page 9] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[9ページ]。
3.3. Lost packets in UDP and other non-TCP packet streams
3.3. UDPの無くなっているパケットと他の非TCPパケットストリーム
Incorrectly decompressed headers of UDP packets and other non-TCP packets are not so well-protected by checksums as TCP packets. There are no sequence numbers that become "off-by-k" and virtually guarantees a failed checksum as there are for TCP. The UDP checksum only covers payload, UDP header, and pseudo header. The pseudo header includes the source and destination addresses, the transport protocol type and the length of the transport packet. Except for those fields, large parts of the IPv6 header are not covered by the UDP checksum. Moreover, other non-TCP headers lack checksums altogether, for example fragments.
UDPパケットと他の非TCPパケットの不当に減圧されたヘッダーはTCPパケットとしてチェックサムによって非常によく保護されていません。 なる一連番号が全くない、「オフである、k、」 実際には、TCPのためにあって、失敗したチェックサムを保証します。 UDPチェックサム、唯一のカバーペイロード、UDPヘッダー、および疑似ヘッダー。 疑似ヘッダーはソースと送付先アドレス、トランスポート・プロトコルタイプ、および輸送パケットの長さを入れます。 それらの分野以外に、IPv6ヘッダーのかなりの部分はUDPチェックサムでカバーされていません。 そのうえ、他の非TCPヘッダーは全体でチェックサム、例えば断片を欠いています。
In order to safely avoid incorrect decompression of non-TCP headers, each version of the context for non-TCP packet streams is identified by a generation, a small number that is carried by the full headers that establish and refresh the context. Compressed headers carry the generation value of the context that were used to compress them. When a decompressor sees that a compressed header carries a generation value other than the generation of its context for that packet stream, the context is not up to date and the packet must be discarded or stored until a full header establishes correct context.
安全に非TCPヘッダーの不正確な減圧を避けるために、非TCPパケットストリームのための文脈の各バージョンは1世代(文脈を確立して、リフレッシュする完全なヘッダーによって運ばれる少ない数)によって特定されます。 圧縮されたヘッダーは彼らを圧縮するのに使用された文脈の世代値を運びます。 減圧装置が、圧縮されたヘッダーがそのパケットストリームのための文脈の世代以外の世代値を運ぶのを見るとき、関係が最新でなく、完全なヘッダーが正しい文脈を確立するまで、パケットを捨てられなければならないか、または保存しなければなりません。
Differential coding is not used for non-TCP streams, so compressed non-TCP headers do not change the context. Thus, loss of a compressed header does not invalidate subsequent packets with compressed headers. Moreover, the generation changes only when the context of a full header is different from the context of the previous full header. This means that losing a full header will make the context of the decompressor obsolete only when the full header would actually have changed the context.
差分符号化が非TCPストリームに使用されないので、圧縮された非TCPヘッダーは文脈を変えません。 したがって、圧縮されたヘッダーの損失は圧縮されたヘッダーと共にその後のパケットを無効にしません。 そのうえ、文脈であることの完全なヘッダーの世代交代だけが前の完全なヘッダーの文脈と異なっています。 これは、完全なヘッダーが実際に文脈を変えただろうというときだけ、完全なヘッダーをなくすのに減圧装置の文脈が時代遅れになることを意味します。
The generation field is 6 bits long so the generation value repeats itself after 64 changes to the context. To avoid incorrect decompression after error bursts or other temporary disruptions, the compressor must not reuse the same generation value after a shorter time than MIN_WRAP seconds. A decompressor which has been disconnected MIN_WRAP seconds or more must wait for the next full header before decompressing. A compressor must wait at least MIN_WRAP seconds after booting before compressing non-TCP headers. Instead of reusing a generation value too soon, a compressor may switch to another CID or send regular headers until MIN_WRAP seconds have passed. The value of MIN_WRAP is found in section 14.
世代分野が長さ6ビットであるので、世代値は文脈への64回の変化の後に繰り返し言います。 誤りがはち切れた後に不正確な減圧か他の一時的な分裂を避けるために、コンプレッサーはMIN_WRAP秒より短い間の後に同じ世代値を再利用してはいけません。 外されたMIN_WRAP秒である減圧装置か以上が減圧する前に、次の完全なヘッダーを待たなければなりません。 非TCPヘッダーを圧縮する前に、コンプレッサーは穂ばらみの少なくともMIN_WRAP秒後を待たなければなりません。 あまりに早く世代値を再利用することの代わりに、MIN_WRAP秒が経過するまで、コンプレッサーは、別のCIDに切り替わるか、またはレギュラーのヘッダーを送るかもしれません。 MIN_WRAPの値はセクション14で見つけられます。
Degermark, et. al. Standards Track [Page 10] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[10ページ]。
3.3.1. Compression Slow-Start
3.3.1. 圧縮遅れた出発
To allow the decompressor to recover quickly from loss of a full header that would have changed the context, full headers are sent periodically with an exponentially increasing period after a change in the context. This technique avoids an exchange of messages between compressor and decompressor used by other compression schemes, such as in [RFC-1553]. Such exchanges can be costly for wireless mobiles as more power is consumed by the transmitter and delay can be introduced by switching between sending and receiving. Moreover, techniques that require an exchange of messages cannot be used over simplex links, such as direct-broadcast satellite channels or cable TV systems, and are hard to adapt to multicast over multi-access links.
減圧装置が文脈を変えた完全なヘッダーの損失からすぐに回復するのを許容するために、文脈における変化の後に指数関数的に増加する期間と共に完全なヘッダーを定期的に送ります。 このテクニックは[RFC-1553]などの他の圧縮技術によって使用されるコンプレッサーと減圧装置の間のメッセージの交換を避けます。 無線モバイルに、そのような交換は、送信機で、より多くのパワーを消費して、送受信を切り換えることによって遅れを導入できるので、高価である場合があります。 そのうえ、メッセージの交換を必要とするテクニックは、直接放送衛星チャンネルかケーブルテレビシステムなどのシンプレクスリンクの上に使用できないで、マルチアクセスリンクの上にマルチキャストに順応しにくいです。
|.|..|....|........|................|..............................
^
Change Sent packets: | with full header, . with compressed header
|.|..|....|........|................|.............................. ^Sentパケットを変えてください: | 完全なヘッダーと共に圧縮されたヘッダー
The picture shows how packets are sent after change. The compressor keeps a variable for each non-TCP packet stream, F_PERIOD, that keeps track of how many compressed headers may be sent between full headers. When the headers of a non-TCP packet stream change so that its context changes, a full header is sent and F_PERIOD is set to one. After sending F_PERIOD compressed headers, a full header is sent. F_PERIOD is doubled each time a full header is sent during compression slow-start.
絵は変化の後にどうパケットを送るかを示しています。 コンプレッサーはそれぞれの非TCPパケットの流れ、何人の圧縮されたヘッダーを完全なヘッダーの間に送るかもしれないかに関する道を保つF_PERIODのために変数を保ちます。 非TCPパケットの流れのヘッダーが変化するので文脈が変化するとき、完全なヘッダーを送ります、そして、F_PERIODは1つに用意ができています。 F_PERIODに圧縮されたヘッダーを送った後に、完全なヘッダーを送ります。 F_PERIODは圧縮遅れた出発の間、完全なヘッダーを送るたびに倍にされます。
3.3.2. Periodic Header Refreshes
3.3.2. 周期的なヘッダーはリフレッシュします。
To avoid losing too many packets if a receiver has lost its context, there is an upper limit, F_MAX_PERIOD, on the number of non-TCP packets with compressed headers that may be sent between header refreshes. If a packet is to be sent and F_MAX_PERIOD compressed headers have been sent since the last full header for this packet stream was sent, a full header must be sent.
受信機であるならあまりに多くのパケットを失うのを避けるのが文脈を失って、F_マックス_PERIOD、上限があって、それが送られるかもしれない圧縮されたヘッダーがある非TCPパケットの数では、ヘッダーはリフレッシュします。 パケットによるマックス_PERIODが圧縮した送られるのとF_であるつもりであるなら、このパケットの流れのための最後の完全なヘッダーを送って以来、ヘッダーを送って、完全なヘッダーを送らなければなりません。
To avoid long periods of disconnection for low data rate packet streams, there is also an upper bound, F_MAX_TIME, on the time between full headers in a non-TCP packet stream. If a packet is to be sent and more than F_MAX_TIME seconds have passed since the last full header was sent for this packet stream, a full header must be sent. The values of F_MAX_PERIOD and F_MAX_TIME are found in section 14.
低データ速度パケットの流れのための長期の断線を避けるために、完全なヘッダーの間には、非TCPパケットの流れに上限も、時のF_マックス_タイム誌があります。 パケットがこのパケットの流れのために最後の完全なヘッダーを送って以来F_マックス_タイム誌秒が経過しているより送って多くであるつもりであるなら、完全なヘッダーを送らなければなりません。 _Fマックス_PERIODと_Fマックス_タイム誌の値はセクション14で見つけられます。
Degermark, et. al. Standards Track [Page 11] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[11ページ]。
3.3.3. Rules for sending Full Headers
3.3.3. 送付Full Headersのための規則
The following pseudo code can be used by the compressor to determine when to send a full header for a non-TCP packet stream. The code maintains two variables:
以下の中間コードはコンプレッサーによって使用されて、非TCPパケットの流れのためにいつ完全なヘッダーを送るかを決定できます。 コードは2つの変数を維持します:
C_NUM -- a count of the number of compressed headers sent
since the last full header was sent.
F_LAST -- the time of sending the last full header.
C_NUM--最後の完全なヘッダー以来送られた圧縮されたヘッダーの数のカウントを送りました。 F_LAST--最後の完全なヘッダーを送る時間。
and uses the functions
機能を使用します。
current_time() return the current time
min(a,b) return the smallest of a and b
現在の時間分(a、b)が最も小さくaとbを返す現在の_時間()リターン
the procedures send_full_header(), increment_generation_value(),
and send_compressed_header()
do the obvious thing.
手順は、_完全な_ヘッダー()を送って、_世代_値()を増加して、圧縮された_ヘッダー()がそうする_に明白なものを送ります。
if ( <this header changes the context> )
if(<、このヘッダーが文脈>を変える、)
C_NUM := 0;
F_LAST := current_time();
F_PERIOD := 1;
increment_generation_value();
send_full_header();
C_ヌム:=0。 F_LASTの:=の現在の_時間()。 F_期間:=1。 _世代_値()を増加してください。 _完全な_ヘッダー()を送ってください。
elseif ( C_NUM >= F_PERIOD )
elseif(C_ヌム>=F_期間)
C_NUM := 0;
F_LAST := current_time();
F_PERIOD := min(2 * F_PERIOD, F_MAX_PERIOD);
send_full_header();
C_ヌム:=0。 F_LASTの:=の現在の_時間()。 F_PERIOD:=分(__2*F PERIOD、Fマックス_PERIOD)。 _完全な_ヘッダー()を送ってください。
elseif ( current_time() > F_LAST + F_MAX_TIME )
elseif(現在の_時間()>F_LAST+F_マックス_タイム誌)
C_NUM := 0;
F_LAST := current_time();
send_full_header();
C_ヌム:=0。 F_LASTの:=の現在の_時間()。 _完全な_ヘッダー()を送ってください。
else
ほか
C_NUM := C_NUM + 1
send_compressed_header();
C_NUM+1が_を送るC_NUM:=は_ヘッダー()を圧縮しました。
endif
endif
Degermark, et. al. Standards Track [Page 12] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[12ページ]。
3.3.4. Cost of sending Header Refreshes
3.3.4. 送付Header Refreshesの費用
If every f'th packet carries a full header, H is the size of a full header, and C is the size of a compressed header, the average header size is
あらゆるf'thパケットが完全なヘッダーを運んで、Hが完全なヘッダーのサイズであり、Cが圧縮されたヘッダーのサイズであるなら、平均したヘッダーサイズはサイズです。
(H-C)/f + C
(H-C) /f+C
For f > 1, the average header size is (H-C)/f larger than a compressed header.
f>1に関しては、平均したヘッダーサイズは圧縮されたヘッダーより大きい(H-C)/fです。
In a diagram where the average header size is plotted for various f values, there is a distinct knee in the curve, i.e., there is a limit beyond which further increasing f gives diminishing returns. F_MAX_PERIOD should be chosen to be a frequency well to the right of the knee of the curve. For typical sizes of H and C, say 48 octets for the full header (IPv6/UDP) and 4 octets for the compressed header, setting F_MAX_PERIOD > 44 means that full headers will contribute less than an octet to the average header size. With a four-address routing header, F_MAX_PERIOD > 115 will have the same effect.
平均したヘッダーサイズが様々なf値のために記入されるダイヤグラムには、カーブに異なったひざがあります、すなわち、fをさらに増加させると収穫逓減が与えられる限界があります。 F_マックス_PERIODは、よくカーブのひざの右への頻度になるように選ばれるべきです。 HとCの典型的なサイズには、_圧縮されたヘッダーのための完全なヘッダー(IPv6/UDP)と4つの八重奏のための48の八重奏であり、Fを設定して、マックス_PERIOD>44が、完全なヘッダーが八重奏ほど平均したヘッダーサイズに貢献しないことを意味すると言ってください。 4アドレスのルーティングヘッダーがあるので、F_マックス_PERIOD>115には、同じ効果があるでしょう。
The default F_MAX_PERIOD value of 256 (section 14) puts the full header frequency well to the right of the knee and means that full headers will typically contribute considerably less than an octet to the average header size. For H = 48 and C = 4, full headers contribute about 1.4 bits to the average header size after reaching the steady-state header refresh frequency determined by the default
256(セクション14)のデフォルトF_マックス_PERIOD価値は、上手に完全なヘッダー頻度をひざの右につけて、完全なヘッダーが八重奏よりかなり通常平均したヘッダーサイズに貢献しないことを意味します。 48とC=4、完全なヘッダーが平均したヘッダーサイズにおよそ1.4ビット貢献するH=に関しては、定常状態ヘッダーに届いて、デフォルトによって決定している頻度をリフレッシュしてください。
F_MAX_PERIOD. 1.4 bits is a very small overhead.
F_マックス_PERIOD。 1.4ビットは非常にわずかなオーバーヘッドです。
After a change in the context, the exponential backoff scheme will initially send full headers frequently. The default F_MAX_PERIOD will be reached after nine full headers and 255 compressed headers have been sent. This is equivalent to a little over 5 seconds for a typical voice stream with 20 ms worth of voice samples per packet.
文脈における変化の後に、指数のbackoff計画は初めは、頻繁に完全なヘッダーを送るでしょう。 9個の完全なヘッダーと255個の圧縮されたヘッダーを送った後にデフォルトF_マックス_PERIODに達するでしょう。 20msとの典型的な声の流れには、これは5秒余りに声のサンプルの1パケットあたり価値があって同等です。
During the whole backoff period, full headers contribute 1.5 octets to the average header size when H = 48 and C = 4. For 20 ms voice samples, it takes less than 1.3 seconds until full headers contribute less than one octet to the average header size, and during these initial 1.3 seconds full headers add less than 4 octets to the average header size. The cost of the exponential backoff is not great and as the headers of non-TCP packet streams are expected to change seldomly, it will be amortized over a long time.
全体のbackoffの期間、Hが48とC=4と等しいと、完全なヘッダーは平均したヘッダーサイズに1.5の八重奏を寄付します。 20個のms声のサンプルに関しては、完全なヘッダーが平均したヘッダーサイズに1つ未満の八重奏を寄付するまで、1.3秒未満取って、これらの初期の1.3秒の間、完全なヘッダーは平均したヘッダーサイズに4つ未満の八重奏を加えます。 指数のbackoffの費用は大きくはありません、そして、非TCPパケットの流れのヘッダーがめったに変えると予想されるとき、それは長い間上で清算されるでしょう。
Degermark, et. al. Standards Track [Page 13] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[13ページ]。
The cost of header refreshes in terms of bandwidth are higher than similar costs for hard state schemes like [RFC-1553] where full headers must be acknowledged by the decompressor before compressed headers may be sent. Such schemes typically send one full header plus a few control messages when the context changes. Hard state schemes require more types of protocol messages and an exchange of messages is necessary. Hard state schemes also need to deal explicitly with various error conditions that soft state handles automatically, for instance the case of one party disappearing unexpectedly, a common situation on wireless links where mobiles may go out of range of the base station.
ヘッダーの費用がリフレッシュする、帯域幅に関して、圧縮されたヘッダーを送るかもしれない前に減圧装置で完全なヘッダーを承認しなければならない[RFC-1553]のような固い状態への同様のコストより高い計画はそうです。 文脈が変化するとき、そのような計画は1つの完全なヘッダープラスにいくつかのコントロールメッセージを通常送ります。 困難な州の計画は、より多くのタイプにプロトコルメッセージを要求します、そして、メッセージの交換が必要です。 また、困難な州の計画は、明らかに、軟性国家が自動的に扱う様々なエラー条件に対処する必要があります、例えば、1回のパーティーが不意に姿を消すケース、モバイルが基地局の範囲から行くかもしれない無線のリンクの上の日常の状況。
The major advantage of the soft state scheme is that no handshakes are needed between compressor and decompressor, so the scheme can be used over simplex links. The costs in terms of bandwidth are higher than for hard state schemes, but the simplicity of the decompressor, the simplicity of the protocol, and the lack of handshakes between compressor and decompressor justifies this small cost. Moreover, soft state schemes are more easily extended to multicast over multi-access links, for example radio links.
軟性国家計画の主要な利点は握手が全くコンプレッサーと減圧装置の間で必要でないのでシンプレクスリンクの上に計画を使用できるということです。 帯域幅に関するコストは困難な州の計画より高いのですが、減圧装置の簡単さ、プロトコルの簡単さ、およびコンプレッサーと減圧装置の間の握手の不足はこのわずかな費用を正当化します。 そのうえ、軟性国家計画は、より容易に例えば、マルチアクセスリンク、ラジオリンクの上のマルチキャストに広げられます。
4. Grouping packets into packet streams
4. パケットをパケットの流れに分類します。
This section explains how packets MAY be grouped together into packet streams for compression. To achieve the best compression rates, packets SHOULD be grouped together such that packets in the same packet stream have similar headers. If this grouping fails, header compression performance will be bad, since the compression algorithm can rarely utilize the existing context for the packet stream and full headers must be sent frequently.
このセクションはパケットがどう圧縮のためのパケットの流れに一緒に分類されるかもしれないかを説明します。 同じパケットの流れにおけるパケットには、最も良い圧縮率、パケットSHOULDを達成するために、一緒に分類されてください。そうすれば、同様のヘッダーがあります。 この組分けが失敗すると、ヘッダー圧縮性能は悪くなるでしょう、圧縮アルゴリズムがめったにパケットの流れのための既存の文脈を利用できないで、頻繁に完全なヘッダーを送らなければならないので。
Grouping is done by the compressor. A compressor may use whatever criterion it finds appropriate to group packets into packet streams. To determine what packet stream a packet belongs to, a compressor MAY
コンプレッサーで、グルーピングします。 コンプレッサーはそれがパケットをパケットの流れに分類するのが適切であることがわかるどんな評価基準も使用するかもしれません。パケットがどんなパケットの流れに属すかを決定するために、コンプレッサーはそうするかもしれません。
a) examine the compressible chain of subheaders (see section 7),
a) 「副-ヘッダー」の圧縮性のチェーンを調べてください(セクション7を見てください)。
b) examine the contents of an upper layer protocol header that
follows the compressible chain of subheaders, for example ICMP
headers, DVMRP headers, or tunneled IPX headers,
b) 例えば、「副-ヘッダー」の圧縮性のチェーンの後をつける上側の層のプロトコルヘッダー、ICMPヘッダー、DVMRPヘッダー、またはトンネルを堀られたIPXヘッダーのコンテンツを調べてください。
c) use information obtained from a resource manager, for example if a
resource manager requests compression for a particular packet
stream and provides a way to identify packets belonging to that
packet stream,
c) 資源管理プログラムから得られた情報を使用してください、例えば、資源管理プログラムが特定のパケットの流れのための圧縮を要求して、そのパケットの流れに属すパケットを特定する方法を提供するなら
Degermark, et. al. Standards Track [Page 14] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[14ページ]。
d) use any other relevant information, for example if routes flap and
the hop limit (TTL) field in a packet stream changes frequently
between n and n+k, a compressor may choose to group the packets
into two different packet streams.
d) いかなる他の関連情報も使用してください、例えば、ルートがばたついて、パケットの流れにおけるホップ限界(TTL)分野がnとn+kの間で頻繁に変化して、コンプレッサーが、パケットを2つの異なったパケットの流れに分類するのを選ぶかもしれないなら。
A compressor is also free not to group packets into packet streams for compression, letting some packets keep their regular headers and passing them through unmodified.
また、コンプレッサーもパケットを圧縮のためのパケットの流れに分類しないように無料です、いくつかのパケットに変更されなく彼らのレギュラーのヘッダーと彼らを通過し突き抜けるのに続けさせて。
As long as the rules for when to send full headers for a non-TCP packet stream are followed and subheaders are compressed as specified in this document, the decompressor is able to reconstruct a compressed header correctly regardless of how packets are grouped into packet streams.
非TCPパケットの流れのためにいつ完全なヘッダーを送るか間の規則が従われていて、「副-ヘッダー」が本書では指定されるように圧縮される限り、パケットがどうパケットの流れに分類されるかにかかわらず減圧装置は正しく圧縮されたヘッダーを再建できます。
4.1 Guidelines for grouping packets
4.1 パケットを分類するためのガイドライン
In this section we give OPTIONAL guidelines for how a compressor may group packets into packet streams for compression.
このセクションでは、私たちはコンプレッサーがどうパケットを圧縮のためのパケットの流れに分類できるようにガイドラインをOPTIONALに与えるか。
Defining fields
分野を定義します。
The defining fields of a header should be present and identical in
all packets belonging to the same packet stream. These fields are
marked DEF in section 7. The defining fields include the flow
label, source and destination addresses of IP headers, final
destination address in routing headers, the next header fields
(for IPv6), the protocol field (IPv4), port numbers (UDP and TCP),
and the SPI in authentication and encryption headers.
ヘッダーの定義分野は、すべてのパケットで同じパケットの流れに属すのが現在であって同じであるべきです。 これらの分野はセクション7のDEFであることが示されます。 定義分野は認証と暗号化ヘッダーに流れラベル、IPヘッダーのソースと送付先アドレス、ルーティングヘッダーの最終的な送付先アドレス、次のヘッダーフィールド(IPv6のための)、プロトコル分野(IPv4)、ポートナンバー(UDPとTCP)、およびSPIを含んでいます。
Fragmented packets
断片化しているパケット
Fragmented and unfragmented packets should never be grouped
together in the same packet stream. The Identification field of
the Fragment header or IPv4 header should not be used to identify
the packet stream. If it was, the first fragment of a new packet
would cause a compression slow-start.
断片化していて非断片化しているパケットは同じパケットの流れで決して一緒に分類されるべきではありません。 パケットの流れを特定するのにFragmentヘッダーかIPv4ヘッダーのIdentification分野を使用するべきではありません。 それがそうなら、新しいパケットの最初の断片は圧縮遅れた出発を引き起こすでしょうに。
No field after a Fragment Header, or an IPv4 header for a
fragment, should be used for grouping purposes.
目的を分類するのにどんなFragment Headerの後の分野も、または断片のためのIPv4ヘッダーも使用するべきではありません。
Upper protocol identification
上側のプロトコル識別
The first next header field identifying a header not described in
section 7 should be used for identifying packet streams, i.e., all
packets with the same DEF fields and the same upper protocol
should be grouped together.
セクション7で説明されなかったヘッダーを特定する次の最初のヘッダーフィールドはパケットの流れを特定するのに使用されるべきです、すなわち、同じDEF分野と同じ上側のプロトコルがあるすべてのパケットが一緒に分類されるべきです。
Degermark, et. al. Standards Track [Page 15] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[15ページ]。
TTL field (Hop Limit field)
TTL分野(ホップLimit分野)
A sophisticated implementation might monitor the TTL (Hop Limit)
field and if it changes frequently use it as a DEF field. This can
occur when there are frequent route flaps so that packets traverse
different paths through the internet.
洗練された実現はTTL(ホップLimit)分野をモニターするかもしれません、そして、それであるなら、変化はDEF分野として頻繁にそれを使用します。 頻繁なルートフラップがあるとき、これが起こることができるので、パケットはインターネットを通して異なった経路を横断します。
Traffic Class field (IPv6), Type of Service field (IPv4)
交通Class分野(IPv6)、Service分野のType(IPv4)
It is possible that the Traffic Class field of the IPv6 header and
the Type of Service of the IPv4 header will change frequently
between packets with otherwise identical DEF fields. A
sophisticated implementation should watch out for this and be
prepared to use these fields as defining fields.
そうでなければ、同じDEF分野に応じてIPv6ヘッダーのTraffic Class分野とIPv4ヘッダーのServiceのTypeがパケットの間で頻繁に変化するのは、可能です。 洗練された実現は、これに注意して、分野を定義するとしてこれらの分野を使用するように準備されるべきです。
When IP packets are tunneled they are encapsulated with an additional IP header at the tunnel entry point and then sent to the tunnel endpoint. To group such packets into packet streams, the inner headers should also be examined to determine the packet stream. If this is not done, full headers will be sent each time the headers of the inner IP packet changes. So when a packet is tunneled, the identifying fields of the inner subheaders should be considered in addition to the identifying fields of the initial IP header.
IPパケットにトンネルを堀ると、それらをトンネルエントリー・ポイントの追加IPヘッダーと共に要約して、トンネル終点に送ります。 また、そのようなパケットをパケットの流れに分類するなら、内側のヘッダーは、パケットの流れを決定するために調べられるべきです。 これが完了していないと、内側のIPパケットのヘッダーが変化するたびに完全なヘッダーを送るでしょう。 それで、パケットがトンネルを堀られるとき、内側の「副-ヘッダー」の特定分野は初期のIPヘッダーの特定分野に加えて考えられるべきです。
An implementation can use other fields for identification than the ones described here. If too many fields are used for identification, performance might suffer because more CIDs will be used and the wrong CIDs might be reused when new flows need CIDs. If too few fields are used for identification, performance might suffer because there are too frequent changes to the context.
実現はここで説明されたもの以外の識別のための分野を使用できます。 あまりに多くの分野が識別に使用されるなら、より多くのCIDsが使用されて、新しい流れがCIDsを必要とするとき間違ったCIDsが再利用されるかもしれないので、性能に苦しむかもしれません。 あまりにわずかな分野しか識別に使用されないなら、文脈への頻繁過ぎる変化があるので、性能に苦しむかもしれません。
We stress that these guidelines are educated guesses. When IPv6 is widely deployed and IPv6 traffic can be analyzed, we might find that other grouping algorithms perform better. We also stress that if the grouping fails, the result will be bad performance but not incorrect decompression. The decompressor can do its task regardless of how the grouping algorithm works.
私たちは、これらのガイドラインが経験に基づいた推測であると強調します。 広くIPv6を配備して、IPv6交通を分析できるとき、私たちは、他の組分けアルゴリズムがよく振る舞うのがわかったかもしれません。 また、私たちは、組分けが失敗するなら、結果が不正確な減圧ではなく、望ましくない市場成果になると強調します。 組分けアルゴリズムがどう利くかにかかわらず減圧装置はタスクを果たすことができます。
5. Size Issues
5. サイズ問題
5.1. Context Identifiers
5.1. 文脈識別子
Context identifiers can be 8 or 16 bits long. Their size is not relevant for finding the context. An 8-bit CID with value two and a 16-bit CID with value two are equivalent.
文脈識別子は、長さ8ビットか16ビットであることができます。 文脈を見つけるのにおいて、それらのサイズは関連していません。 値twoがある8ビットのCIDと値twoがある16ビットのCIDは同等です。
Degermark, et. al. Standards Track [Page 16] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[16ページ]。
The CID spaces for TCP and non-TCP are separate, so a TCP CID and a non-TCP CID never identify the same context. Even if they have the same value. This doubles the available CID space while using the same number of bits for CIDs. It is always possible to tell whether a full or compressed header is for a TCP or non-TCP packet, so no mixups can occur.
TCPのためのCID空間と非TCPが別々であるので、TCP CIDと非TCP CIDは同じ文脈を決して特定しません。 彼らに同じ値があっても。 これはCIDsに同じ数のビットを使用している間、利用可能なCIDスペースを倍にします。 完全であるか圧縮されたヘッダーがTCPか非TCPパケットに賛成するかを言うのは、混乱が全く起こることができないようにいつも可能です。
Non-TCP compressed headers encode the size of the CID using one bit in the second octet of the compressed header. The 8-bit CID allows a minimum compressed header size of 2 octets for non-TCP packets, the CID uses the first octet and the size bit and the 6-bit Generation value fit in the second octet.
非TCPの圧縮されたヘッダーは、圧縮されたヘッダーの2番目の八重奏に1ビットを使用することでCIDのサイズをコード化します。 CIDが非TCPパケットのための2つの八重奏の最小の圧縮されたヘッダーサイズに許容する8ビット、CIDは最初の八重奏を使用します、そして、サイズビットと6ビットのGeneration値は2番目の八重奏をうまくはめ込みます。
For TCP the only available CID size is 8 bits as in [RFC-1144]. 8 bits is probably sufficient as TCP connections are always point-to- point.
TCPに関しては、唯一の有効なCIDサイズが[RFC-1144]のように8ビットです。 8ビットは、いつも、TCP接続がポイントからポイントであるので、たぶん十分です。
The 16 bit CID size may not be needed for point-to-point links; it is intended for use on multi-access links where a larger CID space may be needed for efficient selection of CIDs.
16ビットのCIDサイズはポイントツーポイント接続に必要でないかもしれません。 それは、より大きいCIDスペースがCIDsの効率的な品揃えに必要であるかもしれないマルチアクセスリンクにおける使用のために意図します。
The major difficulty with multi-access links is that several compressors share the CID space of a decompressor. CIDs can no longer be selected independently by the compressors as collisions may occur. This problem may be resolved by letting the decompressors have a separate CID space for each compressor. Having separate CID spaces requires that decompressors can identify which compressor sent the compressed packet, perhaps by utilizing link-layer information as to who sent the link-layer frame. If such information is not available, all compressors on the multi-access link may be enumerated, automatically or otherwise, and supply their number as part of the CID. This latter method requires a large CID space.
マルチアクセスリンクにおける大きな難題は数個のコンプレッサーが減圧装置のCIDスペースを共有するということです。 衝突が起こるかもしれないので、コンプレッサーはもう独自にCIDsを選択できません。 減圧装置に各コンプレッサーのために別々のCIDスペースを持たせることによって、この問題は解決されるかもしれません。 別々のCID空間を持っているのは、減圧装置が、どのコンプレッサーが恐らくだれに関して送られたリンクレイヤ情報を利用するのによる圧縮されたパケットにリンクレイヤフレームを送ったかを特定できるのを必要とします。 そのような情報が利用可能でないなら、マルチアクセスリンクの上のすべてのコンプレッサーが、自動的に列挙されて、そうでなく、CIDの一部としてそれらの番号を供給するかもしれません。 この後者の方法は大きいCIDスペースを必要とします。
5.2. Size of the context
5.2. 文脈のサイズ
The size of the context SHOULD be limited to simplify implementation of compressor and decompressor, and put a limit on their memory requirements. However, there is no upper limit on the size of an IPv6 header as the chain of extension headers can be arbitrarily long. This is a problem as the context is essentially a stored header.
文脈SHOULDのサイズは、コンプレッサーと減圧装置の実現を簡素化するために制限されて、それらのメモリ要件に限界を載せました。 しかしながら、拡張ヘッダーのチェーンが任意に長いことができるように上限が全くIPv6ヘッダーのサイズにありません。 文脈が本質的には格納されたヘッダーであるので、これは問題です。
The configurable parameter MAX_HEADER (see section 14) represents the maximum size of the context, expressed as the maximum sized header that can be stored as context. When a header is larger than MAX_HEADER, only part of it is stored as context. An implementation MUST NOT compress more than the initial MAX_HEADER octets of a header. An implementation MUST NOT partially compress a subheader.
構成可能なパラメタマックス_HEADER(セクション14を見る)は最大が文脈として格納できるヘッダーを大きさで分けたので言い表された文脈の最大サイズを表します。 ヘッダーがマックス_HEADERより大きいときに、それの一部だけが文脈として格納されます。 実現はヘッダーの初期のマックス_HEADER八重奏以上を圧縮してはいけません。 実現は「副-ヘッダー」を部分的に圧縮してはいけません。
Degermark, et. al. Standards Track [Page 17] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[17ページ]。
Thus, the part of the header that is stored as context and is compressed is the longest initial sequence of entire subheaders that is not larger than MAX_HEADER octets.
したがって、文脈として格納されて、圧縮されるヘッダーの一部がマックス_HEADER八重奏ほど大きくない全体の「副-ヘッダー」の最も長い初期の系列です。
5.3. Size of full headers
5.3. 完全なヘッダーのサイズ
It is desirable to avoid increasing the size of packets with full headers beyond their original size, as their size may be optimized for the MTU of the link. Since we assume that the link layer implementation provides the length of packets, we can use the length fields in full headers to pass the values of the CID and the generation to the decompressor.
完全なヘッダーと共にパケットのサイズを彼らの原寸を超えたところまで増加させるのを避けるのは望ましいです、彼らのサイズがリンクのMTUのために最適化されるとき。 リンクレイヤ実現がパケットの長さを提供すると思って、私たちは、CIDと世代の値を減圧装置に通過するのに完全なヘッダーの長さの分野を使用できます。
This requires that the link-layer must not add padding to the payload, at least not padding that can be delivered to the destination link user. It is also required that no extra padding is added after UDP data or in tunneled packets. This allows values of length fields to be calculated from the length of headers and the length of the link-layer frame.
これは、リンクレイヤが、ペイロードにそっと歩いて、それを少なくとも水増ししないのを目的地リンクユーザに渡すことができると言い足してはいけないのを必要とします。 また、どんな余分な詰め物もUDPデータの後かトンネルを堀られたパケットで加えられないのが必要です。 これは、長さの分野の値がヘッダーの長さとリンクレイヤフレームの長さから計算されるのを許容します。
The generation requires one octet and the CID may require up to 2 octets. There are length fields of 2 octets in the IPv6 Base Header, the IPv4 header, and the UDP header.
世代は1つの八重奏を必要とします、そして、CIDは最大2つの八重奏を必要とするかもしれません。 2つの八重奏の長さの分野がIPv6基地のHeader、IPv4ヘッダー、およびUDPヘッダーにあります。
A full TCP header will thus have at least 2 octets available in the IP header to pass the 8 bit CID, which is sufficient. There will be more than two octets available if there is more than one IP header.
完全なTCPヘッダーには、その結果、8の噛み付いているCIDを渡すために、IPヘッダーで利用可能な少なくとも2つの八重奏があるでしょう。(CIDは十分です)。 1個以上のIPヘッダーがあると、利用可能な2つ以上の八重奏があるでしょう。
[RFC-1144] uses the 8 bit Protocol field of the IPv4 header to pass the CID. We cannot use the corresponding method as the sequence of IPv6 extension headers is not fixed and CID values are not disjoint from the legal values of Next Header fields.
[RFC-1144]は、CIDを渡すのにIPv4ヘッダーの8ビットのプロトコル分野を使用します。 修理されなかった拡張ヘッダーとCIDがあるのを評価するIPv6の系列がNext Header分野の法定価格からばらばらにならないで、私たちは対応する方法を使用できません。
An IPv6/UDP or IPv4/UDP packet will have 4 octets available to pass the generation and the CID, so all CID sizes may be used. Fragmented or encrypted packet streams may have only 2 octets available to pass the generation and CID. Thus, 8-bit CIDs may be the only CID sizes that can be used for such packet streams. When IPv6/IPv4 or IPv4/IPv6 tunneling is used, there will be at least 4 octets available, and both CID sizes may be used.
IPv6/UDPかIPv4/UDPパケットには世代とCIDを渡すために利用可能な4つの八重奏があるので、すべてのCIDサイズが使用されるかもしれません。 断片化しているかコード化されたパケットの流れには、世代とCIDを渡すために利用可能な2つの八重奏しかないかもしれません。 したがって、8ビットのCIDsはそのようなパケットの流れに使用できる唯一のCIDサイズであるかもしれません。IPv6/IPv4かIPv4/IPv6トンネリングが使用されているとき、利用可能な少なくとも4つの八重奏があるでしょう、そして、両方のCIDサイズは使用されるかもしれません。
The generation value is passed in the higher order octet of the first length field in the full header. When only one length field is available, the 8-bit CID is passed in the low order octet. When two length fields are available, the lowest two octets of the CID are passed in the second length field and the low order octet of the first length field carries the highest octet of the CID.
世代値は完全なヘッダーの最初の長さの分野の、より高いオーダー八重奏で通過されます。 ワンレン分野だけが利用可能であるときに、8ビットのCIDは下位の八重奏で渡されます。 2つの長さの分野が利用可能であるときに、CIDの最も低い2つの八重奏が2番目の長さの分野で通過されます、そして、最初の長さの分野の下位の八重奏はCIDの最も高い八重奏を運びます。
Degermark, et. al. Standards Track [Page 18] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[18ページ]。
5.3.1. Use of length fields in full TCP headers
5.3.1. 完全なTCPヘッダーにおける長さの分野の使用
Use of first length field:
最初の長さの分野の使用:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length field | LSB of pkt nr | CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+++++++++++++++++長さ分野| pkt nrのLSB| Cid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Use of second length field if available:
利用可能であるなら、2番目の長さの使用はさばきます:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Second length field | MSB of pkt nr | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+++++++++++++++++2番目の長さの分野| pkt nrのMSB| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pkt nr is short for packet sequence number, described in section 11.2.
セクション11.2で説明されたパケット一連番号に、Pkt nrは短いです。
5.3.2. Use of length fields in full non-TCP headers
5.3.2. 完全な非TCPヘッダーにおける長さの分野の使用
Full non-TCP headers with 8-bit CID:
8ビットのCIDがある完全な非TCPヘッダー:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First length field |0|D| Generation| CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+++++++++++++++++最初の長さの分野|0|D| 世代| Cid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Second length field (if avail.) | 0 | Data (if D=1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+++++++++++++++++2番目の長さの分野(利益であるなら) | 0 | データ(D=1であるなら)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Full non-TCP headers with 16-bit CID:
16ビットのCIDがある完全な非TCPヘッダー:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First length field |1|D| Generation| Data (if D=1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+++++++++++++++++最初の長さの分野|1|D| 世代| データ(D=1であるなら)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Second length field | CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+++++++++++++++++2番目の長さの分野| Cid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first bit in the first length field indicates the length of the CID. The Data field is zero if D is zero. The use of the D bit and Data field is explained in section 12.
最初の長さの分野における最初のビットはCIDの長さを示します。 Data分野はDがゼロであるならゼロです。 DビットとData分野の使用はセクション12で説明されます。
Degermark, et. al. Standards Track [Page 19] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[19ページ]。
6. Compressed Header Formats
6. 圧縮されたヘッダー形式
This section uses some terminology (DELTA, RANDOM) defined in section 7.
このセクションはセクション7で定義された何らかの用語(デルタ、RANDOM)を使用します。
a) COMPRESSED_TCP format (similar to [RFC 1144]):
a) COMPRESSED_TCP形式([RFC1144]と同様の):
+-+-+-+-+-+-+-+-+
| CID |
+-+-+-+-+-+-+-+-+
|R O I P S A W U|
+-+-+-+-+-+-+-+-+
| |
+ TCP Checksum +
| |
+-+-+-+-+-+-+-+-+
| RANDOM fields, if any (see section 7) (implied)
- - - - - - - -
| R-octet | (if R=1)
- - - - - - - -
| Urgent Pointer Value (if U=1)
- - - - - - - -
| Window Delta (if W=1)
- - - - - - - -
| Acknowledgment Number Delta (if A=1)
- - - - - - - -
| Sequence Number Delta (if S=1)
- - - - - - - -
| IPv4 Identification Delta (if I=1)
- - - - - - - -
| Options (if O=1)
- - - - - - - -
+-+-+-+-+-+-+-+-+ | Cid| +-+-+-+-+-+-+-+-+ |R O I P S A W U| +-+-+-+-+-+-+-+-+ | | + TCPチェックサム+| | +-+-+-+-+-+-+-+-+ | もしあれば(セクション7を見ます)(含意される)RANDOM分野--、--、--、--、--、--、-| R-八重奏| (R=1であるなら) - - - - - - - - | 緊急のポインタ値(U=1であるなら)--、--、--、--、--、--、--、-| ウィンドウデルタ(W=1であるなら)--、--、--、--、--、--、--、-| 確認応答番号デルタ(A=1であるなら)--、--、--、--、--、--、--、-| 一連番号デルタ(S=1であるなら)--、--、--、--、--、--、--、-| IPv4識別デルタ(I=1であるなら)--、--、--、--、--、--、--、-| オプション(O=1であるなら)--、--、--、--、--、--、--、-
The latter flags in the second octet (IPSAWU) have the same meaning as in [RFC-1144], regardless of whether the TCP segments are carried by IPv6 or IPv4. The C bit has been eliminated because the CID is always present. The context associated with the CID keeps track of the IP version and what RANDOM fields are present. The order between delta fields specified here is exactly as in [RFC-1144]. An implementation will typically scan the context from the beginning and insert the RANDOM fields in order. The RANDOM fields are thus placed before the DELTA fields of the TCP header in the same order as they occur in the original uncompressed header.
2番目の八重奏(IPSAWU)における後者の旗には、[RFC-1144]TCPセグメントがIPv6かIPv4によって運ばれるかどうかにかかわらず同じ意味があります。 CIDがいつも存在しているので、Cビットは排除されました。 CIDに関連している文脈はIPバージョンの動向をおさえます、そして、RANDOMがさばくことは存在しています。 ここで指定されたデルタ分野の間のオーダーはまさに[RFC-1144]のようにそうです。 実現は、整然とした状態で始めからの文脈を通常スキャンして、RANDOM野原を挿入するでしょう。 オリジナルの解凍されたヘッダーに起こるとき同じくらいのTCPヘッダーのデルタ分野が注文される前にRANDOM野原はこのようにして置かれます。
Degermark, et. al. Standards Track [Page 20] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[20ページ]。
The I flag is zero unless an IPv4 header immediately precedes the TCP header. The combined IPv4/TCP header is then compressed as a unit as described in [RFC-1144]. Identification fields in IPv4 headers that are not immediately followed by a TCP header are RANDOM.
IPv4ヘッダーがすぐにTCPヘッダーに先行しない場合、I旗はゼロです。 そして、結合したIPv4/TCPヘッダーは[RFC-1144]で説明されるように一体にして圧縮されます。 すぐにTCPヘッダーによってついて来られていないIPv4ヘッダーの識別分野はRANDOMです。
If the O flag is set, the Options of the TCP header were not the same as in the previous header. The entire Option field are placed last in the compressed TCP header.
O旗が設定されるなら、TCPヘッダーのOptionsは前のヘッダーと同じではありませんでした。 全体のOption野原は最後に圧縮されたTCPヘッダーに置かれます。
If the R flag is set, there were differences between the context and the Reserved field (6 bits) in the TCP header or bit 6 or 7 of the TOS octet (Traffic Class octet) in a IPv4 header (IPv6 header) that immediately precedes the TCP header. An octet with the actual values of the Reserved field and bit 6 and 7 of the TOS or Traffic Class field is then placed immediately after the RANDOM fields. Bits 0-5 of the passed octet is the actual value of the Reserved field, and bits 6 and 7 are the actual values of bits 6 and 7 in the TOS or Traffic Class field. If there is no preceding IP header, bits 6 and 7 are 0. The octet passed with the R flag MUST NOT update the context.
R旗が設定されるなら、文脈とReserved分野(6ビット)の間には、すぐにTCPヘッダーに先行するIPv4ヘッダー(IPv6ヘッダー)のTOS八重奏(トラフィックClass八重奏)の6か7TCPヘッダーかビットに違いがありました。 そして、Reserved分野の実価とTOSかTraffic Class分野のビット6と7による八重奏はRANDOM分野直後置かれます。 通っている八重奏のビット0-5はReserved分野の実価です、そして、ビット6と7はTOSかTraffic Class分野のビット6と7の実価です。 どんな前のIPヘッダーもなければ、ビット6と7は0です。 R旗で通過された八重奏は文脈をアップデートしてはいけません。
NOTE: The R-octet does not update the context because if it did, the nTCP checksum would not guard the receiving TCP from erroneously decompressed headers. Bits 6 and 7 of the TOS octet or Traffic Class octet is expected to change frequently due to Explicit Congestion Notification.
以下に注意してください。 そうするなら、nTCPチェックサムが誤って減圧されたヘッダーから受信TCPを警備しないので、R-八重奏は文脈をアップデートしません。 TOS八重奏かTraffic Class八重奏のビット6と7がExplicit Congestion Notificationのため頻繁に変化すると予想されます。
See section 7.12 and [RFC-1144] for further information on how to compress TCP headers.
どうTCPヘッダーを圧縮するかに関する詳細に関してセクション7.12と[RFC-1144]を見てください。
b) COMPRESSED_TCP_NODELTA header format
b) COMPRESSED_TCP_NODELTAヘッダー形式
+-+-+-+-+-+-+-+-+
| CID |
+-+-+-+-+-+-+-+-+
| RANDOM fields, if any (see section 7) (implied)
+-+-+-+-+-+-+-+-+
| Whole TCP header except for Port Numbers
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ | Cid| +-+-+-+-+-+-+-+-+ | どんな(セクション7を見ます)(暗示する)の+++++++++であることでのRANDOM分野| Port民数記+++++++++を除いた全体のTCPヘッダー
Degermark, et. al. Standards Track [Page 21] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[21ページ]。
c) Compressed non-TCP header, 8 bit CID:
0 7
+-+-+-+-+-+-+-+-+
| CID |
+-+-+-+-+-+-+-+-+
|0|D| Generation|
+-+-+-+-+-+-+-+-+
| data | (if D=1)
- - - - - - - -
| RANDOM fields, if any (section 7) (implied)
- - - - - - - -
c) 8歳の圧縮された非TCPヘッダーはCIDに噛み付きました: 0 7 +-+-+-+-+-+-+-+-+ | Cid| +-+-+-+-+-+-+-+-+ |0|D| 世代| +-+-+-+-+-+-+-+-+ | データ| (D=1であるなら) - - - - - - - - | もしあれば(セクション7)RANDOM分野 (暗示する)です。 - - - - - - - -
d) Compressed non-TCP header, 16 bit CID:
0 7
+-+-+-+-+-+-+-+-+
| msb of CID |
+-+-+-+-+-+-+-+-+
|1|D| Generation|
+-+-+-+-+-+-+-+-+
| lsb of CID |
+-+-+-+-+-+-+-+-+
| data | (if D=1)
- - - - - - - -
| RANDOM fields, if any (section 7) (implied)
- - - - - - - -
d) 16歳の圧縮された非TCPヘッダーはCIDに噛み付きました: 0 7 +-+-+-+-+-+-+-+-+ | CIDのmsb| +-+-+-+-+-+-+-+-+ |1|D| 世代| +-+-+-+-+-+-+-+-+ | CIDのlsb| +-+-+-+-+-+-+-+-+ | データ| (D=1であるなら) - - - - - - - - | もしあれば(セクション7)RANDOM分野 (暗示する)です。 - - - - - - - -
The generation, CID and optional one octet data are followed by relevant RANDOM fields (see section 7) as implied by the compression state, placed in the same order as they occur in the original uncompressed header, followed by the payload.
ペイロードが支えたオリジナルの解凍されたヘッダーに起こるのに応じて同次に置かれた圧縮状態によって含意されるように関連RANDOM分野(セクション7を見る)は世代、CID、および1つの任意の八重奏データのあとに続いています。
7. Compression of subheaders
7. 「副-ヘッダー」の圧縮
This section gives rules for how the compressible chain of subheaders is compressed. These rules MUST be followed. Subheaders that may be compressed include IPv6 base and extension headers, TCP headers, UDP headers, and IPv4 headers. The compressible chain of subheaders extends from the beginning of the header
このセクションは、「副-ヘッダー」の圧縮性のチェーンがどう圧縮されるかために規則を与えます。 これらの規則に従わなければなりません。 圧縮されるかもしれないSubheadersはIPv6ベース、拡張ヘッダー、TCPヘッダー、UDPヘッダー、およびIPv4ヘッダーを含んでいます。 「副-ヘッダー」の圧縮性のチェーンはヘッダーの始まりから広がります。
a) up to but not including the first header that is not an IPv4
header, an IPv6 base or extension header, a TCP header, or a UDP
header, or
またはa) 上がりますが、IPv4ヘッダーでなくて、またIPv6ベースでなくて、また拡張ヘッダーでなくて、またTCPヘッダーでなくて、またまたはUDPヘッダーでもない最初のヘッダーを含んでいない。
b) up to and including the first TCP header, UDP header, Fragment
Header, Encapsulating Security Payload Header, or IPv4 header for
a fragment,
断片のための最初のTCPヘッダー、UDPヘッダー、Fragment Header、Encapsulating Security有効搭載量Header、またはIPv4ヘッダーを含めたb)
Degermark, et. al. Standards Track [Page 22] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[22ページ]。
whichever gives the shorter chain. For example, rules a) and b) both fit a chain of subheaders that contain a Fragment Header and ends at a tunneled IPX packet. Since rule b) gives a shorter chain, the compressible chain of subheaders stops at the Fragment Header.
より短いチェーンに与えます。 例えば、規則a)とb)はともにトンネルを堀られたIPXパケットにおけるFragment Headerと終わりを含む「副-ヘッダー」のチェーンに合います。 規則b)が、より短いチェーンに与えるので、「副-ヘッダー」の圧縮性のチェーンはFragment Headerに止まります。
The following subsections are a systematic classification of how all fields in subheaders are expected to change.
以下の小区分は「副-ヘッダー」のすべての分野が変化するとどう予想されるかに関する系統的な分類です。
NOCHANGE The field is not expected to change. Any change means
that a full header MUST be sent to update the context.
変えない分野が予想されるNOCHANGE。 どんな変化も、文脈をアップデートするために完全なヘッダーを送らなければならないことを意味します。
DELTA The field may change often but usually the difference
from the field in the previous header is small, so that
it is cheaper to send the change from the previous value
rather than the current value. This type of compression
is only used for TCP packet streams.
分野がしばしば変えるかもしれないデルタにもかかわらず、前のヘッダーの分野からの通常違いはそうです。小さく、それが、より安いそうは現行価値よりむしろ前の値から変化を送ります。 このタイプの要約はTCPパケットストリームに使用されるだけです。
RANDOM The field must be included "as-is" in compressed headers,
usually because it changes unpredictably.
RANDOM、通常、予想外に変化するので、圧縮されたヘッダーに「そのままで」分野を含まなければなりません。
INFERRED The field contains a value that can be inferred from
other values, for example the size of the frame carrying
the packet, and thus must not be included in the
compressed header.
INFERRED、分野が他の値から推論できる値を含んでいて、例えばフレームのサイズは、パケットを運んで、その結果、圧縮されたヘッダーに含まれてはいけません。
The classification implies how a compressed header is constructed. No field that is NOCHANGE or INFERRED is present in a compressed header. A compressor obtains the values of NOCHANGE fields from the context identified by the compression identifier, and obtains the values of INFERRED fields from the link-layer implementation, e.g., from the size of the link-layer frame, or from other fields, e.g., by recalculating the IPv4 header checksum. DELTA fields are encoded as the difference to the value in the previous packet in the same packet stream. The decompressor must update the context by adding the value in the compressed header to the value in its context. The result is the proper value of the field. RANDOM fields must be sent "as-is" in the compressed header. RANDOM fields must occur in the same order in the compressed header as they occur in the full header.
分類は圧縮されたヘッダーがどう組み立てられるかを含意します。 NOCHANGEかINFERREDであるどんな分野も圧縮されたヘッダーに存在していません。 コンプレッサーは、圧縮識別子によって特定された文脈からNOCHANGE分野の値を得て、リンクレイヤ実装か、例えば、リンクレイヤフレームのサイズか、他の分野からINFERRED分野の値を得ます、例えば、IPv4ヘッダーチェックサムについて再計算することによって。 デルタ分野は違いとして同じパケットストリームで前のパケットの値にコード化されます。 減圧装置は、圧縮されたヘッダーで文脈の値に価値を高めることによって、文脈をアップデートしなければなりません。 結果は分野の固有値です。 圧縮されたヘッダーで「そのままで」RANDOM野原を送らなければなりません。 完全なヘッダーに起こるのに従って、RANDOM分野は圧縮されたヘッダーに同次で起こらなければなりません。
Fields that may optionally be used to identify what packet stream a packet belongs to according to section 4.1 are marked with the word DEF. To a compressor using the optional guidelines from section 4.1, any difference in corresponding DEF fields between two packets implies that they belong to different packet streams. Moreover, if a DEF field is present in one packet but not in another, the packets belong to different packet streams.
セクション4.1によると、パケットがどんなパケットストリームに属すかを特定するのに任意に使用されるかもしれない分野はDEFという単語で示されます。 セクション4.1からの任意のガイドラインを使用するコンプレッサーに、2つのパケットの間の対応するDEF分野のどんな違いも、異なったパケットストリームに属すのを含意します。そのうえ、DEF分野が1つのパケットに存在していますが、別のものに存在しているというわけではないなら、パケットは異なったパケットストリームに属します。
Degermark, et. al. Standards Track [Page 23] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[23ページ]。
7.1. IPv6 Header [IPv6, section 3]
7.1. IPv6ヘッダー[IPv6、セクション3]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |バージョン| トラフィックのクラス| 流れラベル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ペイロード長| 次のヘッダー| ホップ限界| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + ソースアドレス+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + 送付先アドレス+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version NOCHANGE (DEF)
Traffic Class NOCHANGE (might be DEF, see sect 4.1)
(see also sect 6 a)
Flow Label NOCHANGE (DEF)
Payload Length INFERRED
Next Header NOCHANGE
Hop Limit NOCHANGE (might be DEF, see sect 4.1)
Source Address NOCHANGE (DEF)
Destination Address NOCHANGE (DEF)
バージョンNOCHANGE(DEF)がClass NOCHANGE(DEFであり、セクト4.1を見るかもしれない)を取引する、(また、セクト6a)Flow Label NOCHANGE(DEF)有効搭載量Length INFERRED Next Header NOCHANGE Hop Limit NOCHANGE(DEFであり、セクト4.1を見るかもしれない)ソースAddress NOCHANGE(DEF)目的地Address NOCHANGEを見てください。(クール)です。
The Payload Length field of encapsulated headers must correspond to the length value of the encapsulating header. If not, the header chain MUST NOT be compressed.
カプセル化されたヘッダーの有効搭載量Length分野は要約のヘッダーの長さの値に対応しなければなりません。 そうでなければ、ヘッダーチェーンを圧縮してはいけません。
NOTE: If this the IP header closest to a TCP header, bit 7 of the Traffic Class field can be passed using the R-flag of the compressed TCP header. See section 6 a).
以下に注意してください。 これである、TCPヘッダーの最も近くに、圧縮されたTCPヘッダーのR-旗を使用することでTraffic Class分野のビット7を渡すことができるIPヘッダー セクション6a)を見てください。
This classification implies that the entire IPv6 base header will be compressed away.
この分類は、全体のIPv6ベースヘッダーが遠くに圧縮されるのを含意します。
Degermark, et. al. Standards Track [Page 24] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[24ページ]。
7.2. IPv6 Extension Headers [IPv6, section 4]
7.2. IPv6拡張ヘッダー[IPv6、セクション4]
What extension headers are present and the relative order of them is not expected to change in a packet stream. Whenever there is a change, a full packet header must be sent. All Next Header fields in IPv6 base header and IPv6 extension headers are NOCHANGE.
どんな拡張ヘッダーが出席しているか、そして、彼らの相対オーダがパケットストリームで変化しないと予想されます。 変化があるときはいつも、完全なパケットのヘッダーを送らなければなりません。 IPv6ベースヘッダーとIPv6拡張ヘッダーのすべてのNext Header分野がNOCHANGEです。
7.3. Options [IPv6, section 4.2]
7.3. オプション[IPv6、セクション4.2]
The contents of Hop-by-hop Options and Destination Options extension headers are encoded with TLV "options" (see [IPv6]):
ホップによるHop OptionsとDestination Options拡張ヘッダーのコンテンツはTLV「オプション」でコード化されます([IPv6]を見てください):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | オプションタイプ| Dataレンを選んでください。| データ+++++++++++++++++をゆだねてください、-、--、--、--、--、--、--、--、-
Option Type and Opt Data Len fields are assumed to be fixed for a given packet stream, so they are classified as NOCHANGE. The Option data is RANDOM unless specified otherwise below.
与えられたパケットストリームのためにオプションTypeとOpt Dataレン分野が修理されると思われるので、それらはNOCHANGEとして分類されます。 別の方法で以下で指定されない場合、OptionデータはRANDOMです。
Padding
詰め物
Pad1 option
Pad1オプション
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+
Entire option is NOCHANGE.
全体のオプションはNOCHANGEです。
PadN option
PadNオプション
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | 1 | Dataレンを選んでください。| データ+++++++++++++++++をゆだねてください、-、--、--、--、--、--、--、--、-
All fields are NOCHANGE.
すべての分野がNOCHANGEです。
Degermark, et. al. Standards Track [Page 25] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[25ページ]。
7.4. Hop-by-Hop Options Header [IPv6, section 4.3]
7.4. ホップごとのオプションヘッダー[IPv6、セクション4.3]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 次のヘッダー| Hdr Extレン| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . オプション…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header NOCHANGE
Hdr Ext Len NOCHANGE
次のヘッダーNOCHANGE Hdr ExtレンNOCHANGE
Options TLV coded values and padding.
Classified according to 7.3 above, unless
being a Jumbo Payload option (see below).
オプションTLVは値と詰め物をコード化しました。 上の7.3に従って、Jumbo有効搭載量オプション(以下を見る)でないなら分類されます。
Jumbo Payload option
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 194 |Opt Data Len=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Jumbo Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ジャンボな有効搭載量オプション+++++++++++++++++| 194 |Dataレン=4を選んでください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ジャンボなペイロード長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First two fields are NOCHANGE and Jumbo Payload Length INFERRED. (frame length must be supplied by link layer implementation).
最初の2つの分野が、NOCHANGEとJumbo有効搭載量Length INFERREDです。 (リンクレイヤ実装はフレームの長さを供給しなければなりません。)
NOTE: It is silly to compress the headers of a packet carrying a
Jumbo Payload Option since the relative header overhead is
negligible. Moreover, it is usually a bad idea to send such
large packets over low- and medium-speed links.
以下に注意してください。 相対的なヘッダーオーバーヘッドが取るにたらないのでJumbo有効搭載量Optionを運ぶパケットのヘッダーを圧縮するのは愚かです。 そのうえ、通常、安値とミディアム・スピードリンクの上にそのような大きいパケットを送るのは、悪い考えです。
7.5. Routing Header [IPv6, section 4.4]
7.5. ルート設定ヘッダー[IPv6、セクション4.4]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. type-specific data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 次のヘッダー| Hdr Extレン| ルート設定タイプ| セグメントは残っています。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . タイプ特有のデータ…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All fields of the Routing Header are NOCHANGE.
ルート設定Headerのすべての分野がNOCHANGEです。
Degermark, et. al. Standards Track [Page 26] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[26ページ]。
If the Routing Type is not recognized, it is impossible to determine the final Destination Address unless the Segments Left field has the value zero, in which case the Destination Address is the final Destination Address in the basic IPv6 header.
Segments Left分野には値ゼロがなくて、またルート設定Typeが認識されないなら、最終的なDestination Addressを決定するのが不可能である、その場合、Destination Addressが基本的なIPv6ヘッダーの最終的なDestination Addressです。
In the Type 0 Routing Header, the last address is DEF if (Segments Left > 0).
Type0ルート設定Headerでは、(セグメントLeft>0)であるなら、最後のアドレスはDEFです。
Routing Headers are compressed away completely. This is a big win as the maximum size of the Routing Header is 392 octets. Moreover, Type 0 Routing Headers with one address, size 24 octets, are used by Mobile IP.
ルート設定Headersは遠くに完全に圧縮されます。 ルート設定Headerの最大サイズが392の八重奏であるので、これは思わぬ幸運です。 そのうえ、1つのアドレスがあるType0ルート設定Headers(サイズ24八重奏)はモバイルIPによって使用されます。
7.6. Fragment Header [IPv6, section 4.5]
7.6. 断片ヘッダー[IPv6、セクション4.5]
The first fragment of a packet has Fragment Offset = 0 and the chain of subheaders extends beyond its Fragment Header. If a fragment is not the first (Fragment Offset not 0), there are no subsequent subheaders (unless the chain of subheaders in the first fragment didn't fit entirely in the first fragment).
パケットの最初の断片には、「副-ヘッダー」の0とチェーンがFragment Headerを超えて広げるFragment Offset=があります。 断片が1(0ではなく断片Offset)番目でないなら、どんなその後の「副-ヘッダー」もありません(最初の断片の「副-ヘッダー」のチェーンが最初の断片を完全にうまくはめ込んだなら)。
Since packets may be reordered before reaching the compression point, and some fragments may follow other routes through the network, a compressor cannot rely on seeing the first fragment before other fragments. This implies that information in subheaders following the Fragment Header of the first fragment cannot be examined to determine the proper packet stream for other fragments.
圧密点に達する前に、パケットが再命令されるかもしれなくて、いくつかの断片がネットワークを通して他のルートに従うかもしれないので、コンプレッサーは他の断片の前で最初の断片を見るのを当てにされることができません。 これは、他の断片のために適切なパケットストリームを決定するために最初の断片のFragment Headerに続く「副-ヘッダー」の情報を調べることができないのを含意します。
It is possible to design compression schemes that can compress subheaders after the Fragment Header, at least in the first fragment, but to avoid complicating the rules for sending full headers and the rules for compression and decompression, the chain of subheaders that follow a Fragment Header MUST NOT be compressed.
Fragment Headerの後に「副-ヘッダー」を圧縮できる圧縮技術を設計するのは可能です、少なくとも最初の断片で、しかし、送付の完全なヘッダーのための規則とFragment Headerに続く「副-ヘッダー」の圧縮と減圧、チェーンのための規則を複雑にするのを避けるのは圧縮されているはずがありません。
The fields of the Fragment Header are classified as follows.
Fragment Headerの分野は以下の通り分類されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Reserved | Fragment Offset |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 次のヘッダー| 予約されます。| 断片オフセット|Res|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header NOCHANGE
Reserved NOCHANGE
Res RANDOM
M flag RANDOM
Fragment Offset RANDOM
Identification RANDOM
次のHeader NOCHANGE Reserved NOCHANGE Res RANDOM M旗のRANDOM Fragment Offset RANDOM Identification RANDOM
Degermark, et. al. Standards Track [Page 27] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[27ページ]。
This classification implies that a Fragment Header is compressed down to 6 octets. The minimum IPv6 MTU is 1280 octets so most fragments will be at least 1280 octets. Since the 6 octet overhead of the compressed fragment header is amortized over a fairly large packet, the additional complexity of more sophisticated compression schemes is not justifiable.
この分類は、Fragment Headerが6つの八重奏まで圧縮されるのを含意します。 最小のIPv6 MTUが1280の八重奏であるので、ほとんどの断片が少なくとも1280の八重奏になるでしょう。 圧縮された断片ヘッダーの6八重奏オーバーヘッドがかなり大きいパケットの上で清算されるので、より洗練された圧縮技術の追加複雑さは正当ではありません。
NOTE: The Identification field is RANDOM instead of NOCHANGE
to avoid one compression slow-start per original packet.
以下に注意してください。 Identification分野はオリジナルのパケットあたり1つの圧縮遅れた出発を避けるNOCHANGEの代わりにRANDOMです。
Grouping of fragments according to the optional guidelines in section4.1:
section4.1の任意のガイドラインに従った断片の組分け:
Fragments and unfragmented packets should not be grouped
together.
断片と非断片化しているパケットを一緒に分類するべきではありません。
Port numbers cannot be used to identify the packet stream because
port numbers are not present in every fragment. To adhere to the
uniqueness rules for the Identification value, a fragmented
packet stream is identified by the combination of Source Address
and (final) Destination Address.
ポートナンバーがあらゆる断片に存在しているというわけではないのでパケットストリームを特定するのにポートナンバーを使用できません。 Identification値のためにユニークさの規則を固く守るために、断片化しているパケットストリームはSource Addressと(最終的)の目的地Addressの組み合わせで特定されます。
NOTE: The Identification value is NOT used to identify the
packet stream. This avoids using a new CID for each packet and
saves the cost of the associated compression slow-start. We
expect that the unfragmentable part of the headers will not
change too frequently, if it does thrashing may occur.
以下に注意してください。 Identification値は、パケットストリームを特定するのに使用されません。 これは、各パケットに新しいCIDを使用するのを避けて、関連圧縮遅れた出発の費用を節約します。 私たちはヘッダーの「非-断片-可能」一部があまりに頻繁に変化しないで、そうするなら打つことが起こるかもしれないと予想します。
7.7. Destination Options Header [IPv6, section 4.6]
7.7. 目的地オプションヘッダー[IPv6、セクション4.6]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 次のヘッダー| Hdr Extレン| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . オプション…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header NOCHANGE
Hdr Ext Len NOCHANGE
次のヘッダーNOCHANGE Hdr ExtレンNOCHANGE
Options TLV coded values and padding.
Compressed according to 7.3 above.
オプションTLVは値と詰め物をコード化しました。 上の7.3に従って、圧縮されています。
The only Destination Options defined in [IPv6] are the padding options.
[IPv6]で定義された唯一のDestination Optionsが詰め物オプションです。
Degermark, et. al. Standards Track [Page 28] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[28ページ]。
7.8. No Next Header [IPv6, section 4.7]
7.8. いいえ、次のヘッダー[IPv6、セクション4.7]
Covered by rules for IPv6 Header Extensions (7.2).
規則で、IPv6 Header Extensions(7.2)のためにカバーされます。
7.9. Authentication Header [RFC-2402, section 3.2]
7.9. 認証ヘッダー[RFC-2402、セクション3.2]
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+---------------+---------------+---------------+---------------+
| Next Header | Length | RESERVED |
+---------------+---------------+---------------+---------------+
| Security Parameters Index (SPI) |
+---------------+---------------+---------------+---------------+
| |
+ Authentication Data (variable number of 32-bit words) |
| |
+---------------+---------------+---------------+---------------+
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 +---------------+---------------+---------------+---------------+ | 次のヘッダー| 長さ| 予約されます。| +---------------+---------------+---------------+---------------+ | セキュリティパラメタインデックス(SPI)| +---------------+---------------+---------------+---------------+ | | + 認証Data(可変数の32ビットの単語)| | | +---------------+---------------+---------------+---------------+
Next Header NOCHANGE
Length NOCHANGE
Reserved NOCHANGE
SPI NOCHANGE (DEF)
Authentication Data RANDOM
次のヘッダーNOCHANGE長さのNOCHANGEは無作為の状態でNOCHANGE SPI NOCHANGEの(クール)の認証データを予約しました。
[RFC-1828] specifies how to do authentication with keyed MD5, the authentication method all IPv6 implementations must support. For this method, the Authentication Data is 16 octets.
[RFC-1828]は合わせられたMD5、すべてのIPv6実装がサポートしなければならない認証方法で認証する方法を指定します。 このメソッドのために、Authentication Dataは16の八重奏です。
7.10. Encapsulating Security Payload Header [RFC-2406, section 3.1]
7.10. セキュリティ有効搭載量がヘッダーであるとカプセル化します。[RFC-2406、セクション3.1]
This header implies that the subsequent parts of the packet are encrypted. Thus, no further header compression is possible on subsequent headers as encryption is typically already performed when the compressor sees the packet.
このヘッダーは、パケットのその後の一部が暗号化されていると暗示します。 したがって、コンプレッサーがパケットを見ると暗号化が既に通常実行されるとき、さらなるどんなヘッダー圧縮もその後のヘッダーで可能ではありません。
However, when the ESP Header is used in tunnel mode an entire IP packet is encrypted, and the headers of that packet MAY be compressed before the packet is encrypted at the entry point of the tunnel. This means that it must be possible to feed an IP packet and its length to the decompressor, as if it came from the link-layer. The mechanisms for dealing with reordering described in section 11 MUST also be used, as packets can be reordered in a tunnel.
しかしながら、超能力Headerがトンネルモードで使用されるとき、全体のIPパケットは暗号化されています、そして、パケットがトンネルのエントリー・ポイントで暗号化される前にそのパケットのヘッダーは圧縮されているかもしれません。 これは、IPパケットとその長さを減圧装置に提供するのが可能であるに違いないことを意味します、まるでリンクレイヤから来るかのように。 また、セクション11で説明された再命令に対処するためのメカニズムを使用しなければなりません、トンネルでパケットを再命令できるとき。
Degermark, et. al. Standards Track [Page 29] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[29ページ]。
+---------------+---------------+---------------+---------------+
| Security Association Identifier (SPI), 32 bits |
+===============+===============+===============+===============+
| Opaque Transform Data, variable length |
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+ | セキュリティAssociation Identifier(SPI)、32ビット| +===============+===============+===============+===============+ | 不透明なTransform Data、可変長| +---------------+---------------+---------------+---------------+
SPI NOCHANGE (DEF)
Opaque Transform Data RANDOM
SPI NOCHANGE(クールな)は無作為の状態で変換データについて不透明にします。
Everything after the SPI is encrypted and is not compressed.
SPIの後のすべてが、暗号化されていて、圧縮されません。
7.11. UDP Header
7.11. UDPヘッダー
The UDP header is described in [RFC-768].
UDPヘッダーは[RFC-768]で説明されます。
The Next Header field (IPv6) or Protocol field (IPv4) in the preceding subheader is DEF.
前の「副-ヘッダー」のNext Header分野(IPv6)かプロトコル分野(IPv4)がDEFです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースポート| 仕向港| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Port NOCHANGE (DEF)
Destination Port NOCHANGE (DEF)
Length INFERRED
Checksum RANDOM, unless it is zero,
in which case it is NOCHANGE.
ソースPort NOCHANGE(DEF)目的地Port NOCHANGE(DEF)長さのINFERRED Checksum RANDOM、ゼロでないなら、その場合、それはNOCHANGEです。
The Length field of the UDP header MUST match the Length field(s) of preceding subheaders, i.e, there must not be any padding after the UDP payload that is covered by the IP Length.
UDPヘッダーのLength分野は「副-ヘッダー」に先行するLength分野に合わなければなりません、i.。e、IP LengthでカバーされているUDPペイロードの後に、少しの詰め物もあるはずがありません。
The UDP header is typically compressed down to 2 octets, the UDP checksum. When the UDP checksum is zero (which it cannot be with IPv6), it is likely to be so for all packets in the flow and is defined to be NOCHANGE. This saves 2 octets in the compressed header.
UDPヘッダーは2つの八重奏、UDPチェックサムまで通常圧縮されます。 UDPチェックサムがゼロ(IPv6と共にそれがそうであるはずがない)であるときに、それは、したがって、である流れにおけるすべてのパケットにありそうであり、NOCHANGEになるように定義されます。 これは圧縮されたヘッダーの2つの八重奏を保存します。
7.12. TCP Header
7.12. TCPヘッダー
The TCP header is described in [RFC-793].
TCPヘッダーは[RFC-793]で説明されます。
The Next Header field (IPv6) or Protocol field (IPv4) in the preceding subheader is DEF.
前の「副-ヘッダー」のNext Header分野(IPv6)かプロトコル分野(IPv4)がDEFです。
Degermark, et. al. Standards Track [Page 30] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[30ページ]。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset| Reserved |U|A|P|R|S|F| Window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースポート| 仕向港| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 確認応答番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 相殺されます。| 予約されます。|U|A|P|R|S|F| 窓| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| 緊急の指針| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション| 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U, A, P, R, S, and F stands for Urg, Ack, Psh, Rst, Syn, and Fin.
U、A、P、R、S、およびFはUrg、Ack、Psh、Rst、Syn、およびFinを表します。
There are two ways to compress the TCP header.
TCPヘッダーを圧縮する2つの方法があります。
7.12.1. Compressed with differential encoding
7.12.1. 特異なコード化で、圧縮されます。
Source Port NOCHANGE (DEF)
Destination Port NOCHANGE (DEF)
Sequence Number DELTA
Acknowledgment Number DELTA
Offset NOCHANGE
Reserved DELTA (if differs from context,
set R-flag in flag octet
and send absolute value
as described in 6 a.)
Urg,Psh RANDOM (placed in flag octet)
Ack INFERRED to be 1
Rst,Syn,Fin INFERRED to be 0
Window DELTA (if change in Window,
set W-flag in flag octet
and send difference)
Checksum RANDOM
Urgent Pointer DELTA (if Urg is set, send
absolute value)
Options, Padding DELTA (if change in Options,
set O-flag and send
whole Options, Padding)
ソースPort NOCHANGE(DEF)目的地Port NOCHANGE(DEF)系列NumberデルタAcknowledgment NumberデルタOffset NOCHANGE Reservedデルタ(文脈と異なっていて、設定されるなら、旗の八重奏でRで弛んでください、そして、6a.で説明されるように絶対値を送ってください) Urg、1Rst、Syn、0つのWindowデルタ(Windowにおける変化であるなら、W-旗を旗の八重奏にはめ込んでください、そして、違いを送る)チェックサムRANDOM Urgent Pointerデルタ(Urgが用意ができているなら、絶対値を送る)のオプション、PaddingデルタであるFin INFERREDであるPsh RANDOM(旗の八重奏に置かれる)Ack INFERRED(Optionsにおける変化であるなら、O-旗を設定してください、そして、全体のOptions、Paddingを送ってください)
A packet with a TCP header compressed according to the above must be indicated to be of type COMPRESSED_TCP. The compressed header is described in section 6.
タイプCOMPRESSED_TCPにはあるようにTCPヘッダーが上記で圧縮されているパケットを示さなければなりません。 圧縮されたヘッダーはセクション6で説明されます。
Degermark, et. al. Standards Track [Page 31] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[31ページ]。
This method is essentially the differential encoding techniques of Jacobson, described in [RFC-1144], the differences being the placement of the compressed TCP header fields (see section 6), the use of the O-flag, the use of the R-flag, and elimination of the C-flag. The O-flag allows compression of the TCP header when the Timestamp option is used and the Options fields changes with each header.
この方法は本質的には[RFC-1144]で説明された、ジェーコブソンの特異なコード化のテクニックです、違いが圧縮されたTCPヘッダーフィールド(セクション6を見る)のプレースメントと、O-旗の使用と、R-旗の使用と、C-旗の除去であり。 Timestampオプションが使用されていて、Optionsが各ヘッダーと共に変化をさばくとき、O-旗はTCPヘッダーの圧縮を許します。
DELTA values (except for Reserved field and Options, Padding) MUST be coded as in [RFC-1144]. A Reserved field value passed with the R-flag MUST NOT update the context at compressor or decompressor.
[RFC-1144]のようにデルタ値(Reserved分野とOptions以外のPadding)をコード化しなければなりません。 R-旗で通過されたReserved分野価値はコンプレッサーか減圧装置で文脈をアップデートしてはいけません。
7.12.2. Without differential encoding
7.12.2. 特異なコード化なしで
Source Port NOCHANGE (DEF)
Destination Port NOCHANGE (DEF)
ソースのポートのNOCHANGEの(クール)の仕向港NOCHANGE(クール)です。
(all the rest) RANDOM
(すべての残り) RANDOM
The Identification field in a preceding IPv4 header is RANDOM.
前のIPv4ヘッダーのIdentification分野はRANDOMです。
A packet with a TCP header compressed according to the above must be indicated to be of type COMPRESSED_TCP_NODELTA. It uses the same CID space as COMPRESSED_TCP packets, and the header MUST be saved as context. The compressed header is described in section 6.
タイプCOMPRESSED_TCP_NODELTAにはあるようにTCPヘッダーが上記で圧縮されているパケットを示さなければなりません。 それはCOMPRESSED_TCPパケットと同じCIDスペースを使用します、そして、文脈としてヘッダーを救わなければなりません。 圧縮されたヘッダーはセクション6で説明されます。
This packet type can be sent as the response to a header request instead of sending a full header, can be used over links that reorder packets, and can be sent instead of a full header when there are changes that cannot be represented by a compressed header. A sophisticated compressor can switch to sending only COMPRESSED_TCP_NODELTA headers when the packet loss frequency is high.
完全なヘッダーを送ることの代わりにヘッダー要求への応答としてこのパケットタイプを送ることができて、使用されているのが、その追加注文パケットをリンクして、変化があるとき、完全なヘッダーの代わりに送って、圧縮されたヘッダーがそれを表すことができないということであるかもしれないということであることができます。 精巧なコンプレッサーはパケット損失頻度が高いときに_TCP_NODELTAヘッダーをCOMPRESSEDだけに送るのに切り替わることができます。
Degermark, et. al. Standards Track [Page 32] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[32ページ]。
7.13. IPv4 header [RFC-791, section 3.1]
7.13. IPv4ヘッダー[RFC-791、セクション3.1]
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |バージョン| IHL|サービスのタイプ| 全長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別|旗| 断片オフセット| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生きる時間| プロトコル| ヘッダーチェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付先アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション| 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There are two ways to compress the IPv4 header
IPv4ヘッダーを圧縮する2つの方法があります。
a) If the IPv4 header is not for a fragment (MF flag is not set and
Fragment Offset is zero) and there are no options (IHL is 5), it
is classified as follows
a) IPv4ヘッダーが断片に賛成しないで(MF旗は設定されません、そして、Fragment Offsetはゼロです)、またオプションが全くなければ(IHLは5歳です)、それは以下の通り分類されます。
Version NOCHANGE (DEF)
IHL NOCHANGE (DEF, must be 5)
Type of Service NOCHANGE (might be DEF, see sect 4.1)
(see also 6 a)
Total Length INFERRED (from link-layer implementation
or encapsulating IP header)
Service NOCHANGE(DEFであり、セクト4.1を見るかもしれない)のバージョンNOCHANGE(DEF)IHL NOCHANGE(DEFは5歳であるに違いない)タイプ、(また、6a)Total Length INFERREDを見てください。(リンクレイヤ実現かIPヘッダーをカプセルに入れるのからの)
Identification DELTA/ (If the Protocol field has the
(value corresponding to TCP)
RANDOM (otherwise)
識別デルタ/、(プロトコル分野には、(TCPに対応する値)RANDOMがあります。(そうでなければ)
Flags NOCHANGE (MF flag must not be set)
Fragment Offset NOCHANGE (must be zero)
Time to Live NOCHANGE (might be DEF, see sect 4.1)
Protocol NOCHANGE
Header Checksum INFERRED (calculated from other fields)
Source Address NOCHANGE (DEF)
Destination Address NOCHANGE (DEF)
Options, Padding (not present)
Live NOCHANGE(DEFであり、セクト4.1を見るかもしれない)プロトコルNOCHANGE Header Checksum INFERRED(他の分野から、計算される)ソースAddress NOCHANGE(DEF)目的地Address NOCHANGE(DEF)オプション、PaddingにNOCHANGE(MF旗を設定してはいけない)断片Offset NOCHANGE(ゼロでなければならない)時間に旗を揚げさせます。(現在でない)です。
Degermark, et. al. Standards Track [Page 33] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[33ページ]。
Note: When a TCP header immediately follows, the IPv4 and TCP
header MUST be compressed as a unit as described in section 6.
Bits 6 and 7 of the Type of Service field (bits 14 and 15 of the
first word) can then be passed using the R-flag (see section 6
a).
以下に注意してください。 TCPヘッダーがすぐに続くとき、セクション6で説明されるユニットとしてIPv4とTCPヘッダーを圧縮しなければなりません。 次に、R-旗を使用することでビット6と7のService分野(最初の単語のビット14と15)のTypeを渡すことができます。(セクション6a)を見てください。
b) If the IPv4 header is for a fragment (MF bit set or Fragment
Offset nonzero), or there are options (IHL > 5), all fields are
RANDOM (i.e., if the header is compressed all fields are sent
as-is and not compressed). This classification allows compression
of the tunnel header, but not the fragment header, when fragments
are tunneled. If the IPv4 header is for a fragment it ends the
compressible chain of subheaders, i.e., it must be the last
subheader to be compressed. If the IPv4 header has options but
is not for a fragment it does not end the compressible chain of
subheaders, so subsequent subheaders can be compressed.
b) IPv4ヘッダーが断片に賛成するか(MFはセットかFragment Offset非零に噛み付きました)、またはオプション(IHL>5)があれば、すべての分野がRANDOM(すなわち、ヘッダーが圧縮されるなら、すべての野原が、そのままで送られて、圧縮されるというわけではない)です。 断片がトンネルを堀られるとき、この分類は断片ヘッダーではなく、トンネルヘッダーの圧縮を許します。 IPv4ヘッダーが断片に賛成するなら、「副-ヘッダー」の圧縮性のチェーンを終わらせます、すなわち、最後の圧縮されるべき「副-ヘッダー」であるに違いありません。 IPv4ヘッダーがオプションを持っていますが、断片に賛成しないなら「副-ヘッダー」の圧縮性のチェーンを終わらせないので、その後の「副-ヘッダー」を圧縮できます。
A compressor that follows the optional guidelines of section 4.1 will in case a) use the Version, Source Address and Destination Address to define the packet stream, together with the fact that there are no IPv4 options and that this is not a fragment.
セクション4.1の任意のガイドラインに従うコンプレッサーはパケットの流れを定義するのに場合a)にバージョン、Source Address、およびDestination Addressを使用するでしょう、IPv4オプションが全くなくて、またこれが断片でないという事実と共に。
Case b) can define two kinds of packet streams depending on whether the IPv4 header is for a fragment or not.
ケースb)はIPv4ヘッダーが断片に賛成するかに依存する2種類のパケットの流れを定義できます。
If the IPv4 header in case b) is for a fragment, a compressor following the optional guidelines will use that fact together with the Version, Source Address, and Destination Address to determine the packet stream.
場合b)におけるIPv4ヘッダーが断片に賛成すると、任意のガイドラインに従うコンプレッサーは、パケットの流れを決定するのにバージョン、Source Address、およびDestination Addressと共にその事実を使用するでしょう。
If the IPv4 header in case b) is not for a fragment, it must have options. A compressor following the optional guidelines will use that fact, but not the size of the options, together with the Version, Source Address, and Destination Address to determine the packet stream.
場合b)におけるIPv4ヘッダーが断片に賛成しないなら、それには、オプションがなければなりません。 任意のガイドラインに従うコンプレッサーは、パケットの流れを決定するのにバージョン、Source Address、およびDestination Addressと共にサイズではなく、オプションのその事実を使用するでしょう。
7.14. Minimal Encapsulation header [RFC-2004, section 3.1]
7.14. 最小量のEncapsulationヘッダー[RFC-2004、セクション3.1]
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol |S| reserved | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (if present) Original Source Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | プロトコル|S| 予約されます。| ヘッダーチェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オリジナルの送付先アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : (存在しているなら) 一次資料アドレス: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Degermark, et. al. Standards Track [Page 34] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[34ページ]。
Protocol NOCHANGE
Original Source Address Present (S) NOCHANGE
reserved NOCHANGE
Header Checksum INFERRED (calculated from
other values)
Original Destination Address NOCHANGE
Original Source Address NOCHANGE (present only
if S=1)
プロトコルNOCHANGE Original Source Address Present(S)NOCHANGEはNOCHANGE Header Checksum INFERRED(他の値から、計算される)のオリジナルのDestination Address NOCHANGE Original Source Address NOCHANGEを予約しました。(S=1である場合にだけ提示する、)
This header is likely to be used by Mobile IP.
このヘッダーはモバイルIPによって使用されそうです。
8. Changing context identifiers
8. 文脈識別子を変えます。
On a point-to-point link, the compressor has total knowledge of what CIDs are in use at the decompressor and may change what CID a packet stream uses or reuse CIDs at will.
ポイントツーポイント接続の上では、コンプレッサーは、減圧装置でCIDsが使用での何であるかに関する総知識を持って、パケットの流れがどんなCIDを使用するかを変えるか、またはCIDsを自由自在に再利用するかもしれません。
Each non-TCP CID is associated with a context with a generation value. To avoid too rapid generation wrap-around and potential incorrect decompression, an implementation MUST avoid wrap-around of the generation value in less than MIN_WRAP seconds (see section 14).
それぞれの非TCP CIDは世代値で文脈に関連しています。 急速過ぎる世代巻きつけて着るドレスと潜在的不正確な減圧を避けるために、実現はMIN_WRAP秒以下で世代価値の巻きつけて着るドレスを避けなければなりません(セクション14を見てください)。
To aid in avoiding wrap-around, the generation value associated with a CID MUST NOT be reset when changing to a new packet stream. Instead, a compressor MUST increment the generation value by one when using the CID for a new non-TCP packet stream.
巻きつけて着るドレス、値がCID MUST NOTに関連づけた世代を避ける際に支援するには、新しいパケットの流れに変化するときには、リセットされてください。 新しい非TCPパケットの流れにCIDを使用するとき、代わりに、コンプレッサーは世代値を1つ増加しなければなりません。
9. Rules for dropping or temporarily storing packets
9. 低下するか、または一時パケットを格納するための規則
When a decompressor receives a packet with a compressed TCP header with CID C, it MUST be discarded when the context for C has not been initialized by a full header.
減圧装置が圧縮されたTCPヘッダーと共にCID Cでパケットを受けるとき、C文脈が完全なヘッダーによって初期化されていないとき、それを捨てなければなりません。
When a decompressor receives a packet with a compressed non-TCP header with CID C and generation G, the header must not be decompressed using the current context when
減圧装置が圧縮された非TCPヘッダーと共にCID Cと世代Gでパケットを受けるとき、現在の背景を使用することでヘッダーを減圧してはいけない、いつ
a) the decompressor has been disconnected from the compressor for
more than MIN_WRAP seconds, because the context might be
obsolete even if it has generation G.
a) 減圧装置はMIN_WRAP秒以上でコンプレッサーから外されました、それに世代Gがいても文脈が時代遅れであるかもしれないので。
b) the context for C has a generation other than G.
b) C文脈には、Gを除いた1世代がいます。
In case a) and b) the packet may either be
a)とb) パケットがあるといけないかもしれないので
i) discarded immediately, or else
または、すぐに捨てられたi)
Degermark, et. al. Standards Track [Page 35] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[35ページ]。
ii) stored temporarily until the context is updated by a packet
with a full non-TCP header with CID C and generation G, after
which the header can be decompressed.
パケットはCID Cと世代Gがある完全な非TCPヘッダーと共に文脈まで一時格納されたii)をアップデートします。(その時、ヘッダーを減圧したことができました後)。
Packets stored in this manner MUST be discarded when
この様に格納されたパケットを捨てなければならない、いつ
*) receiving full or compressed non-TCP headers with CID C
and a generation other than G,
*)、Gを除いたCID Cと1世代と共に完全であるか圧縮された非TCPヘッダーを受けます。
*) the decompressor has not received packets with CID C in
the last MIN_WRAP seconds.
*)、減圧装置は最後のMIN_WRAP秒にCID Cと共にパケットを受けていません。
When full headers are lost, a decompressor can receive compressed non-TCP headers with a generation value other than the generation of its context. Rule ii) allows the decompressor to store such headers until they can be decompressed using the correct context.
完全なヘッダーが迷子になっているとき、減圧装置は文脈の世代以外の世代値で圧縮された非TCPヘッダーを受けることができます。 規則ii)で、減圧装置は正しい文脈を使用することで彼らを減圧できるまでそのようなヘッダーを格納できます。
10. Low-loss header compression for TCP
10. TCPのための低い損失ヘッダー圧縮
Since fewer bits are transmitted per packet with header compression, the packet loss rate is lower with header compression than without, for a fixed bit-error rate. This is beneficial for links with high bit-error rates such as wireless links.
より少ないビットがヘッダー圧縮でパケット単位で伝えられるのでパケット損失率がヘッダー圧縮について低い、固定ビット誤り率のために。 無線のリンクなどの高いビット誤り率とのリンクに、これは有益です。
However, since TCP headers are compressed using differential encoding, a single lost TCP segment can ruin an entire TCP sending window because the context is not incremented properly at the decompressor. Subsequent headers will therefore be decompressed to be different than before compression and discarded by the TCP receiver because the TCP checksum fails.
しかしながら、TCPヘッダーが特異なコード化を使用することで圧縮されるとき、文脈が減圧装置で適切に増加されないので、ただ一つの無くなっているTCPセグメントは全体のTCP送付の窓を破滅させることができます。 したがって、TCPチェックサムが失敗するので、その後のヘッダーは、圧縮の前より異なるように減圧されて、TCP受信機によって捨てられるでしょう。
A TCP connection in the wide area where the last hop is over a medium-speed lossy link, for example a wireless LAN, will then have poor performance with traditional header compression because the delay-bandwidth product is relatively large and the bit-error rate relatively high. For a 2 Mbit/s wireless LAN and an end-to-end RTT of 200 ms, the delay-bandwidth product is 50 kbyte. That is equivalent to about 97 512-octet segments with compressed headers. Each loss can thus be multiplied by a factor of 100.
そして、遅れ帯域幅生成物が比較的大きく、ビット誤り率が比較的高いので、ミディアム・スピード損失性リンクの上に最後のホップがある広い領域でのTCP関係(例えば、無線LAN)には伝統的なヘッダー圧縮による不十分な性能があるでしょう。 2メガビット/s無線LANと終わりから終わりへの200msのRTTに関しては、遅れ帯域幅生成物は50キロバイトです。 圧縮されたヘッダーに、それはおよそ97の512八重奏のセグメントに同等です。 その結果、100の要素を各損失に掛けることができます。
This section describes two simple mechanisms for quick repair of the context. With these mechanisms header compression will improve TCP throughput over lossy links as well as links with low bit-error rates.
このセクションは文脈の迅速な修理のために2つの簡単なメカニズムについて説明します。 これらのメカニズムで、ヘッダー圧縮は低ビット誤り率とのリンクと同様に損失性リンクの上にTCPスループットを改良するでしょう。
Degermark, et. al. Standards Track [Page 36] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[36ページ]。
10.1. The "twice" algorithm
10.1. 「二度」というアルゴリズム
The decompressor may compute the TCP checksum to determine if its context is not updated properly. If the checksum fails, the error is assumed to be caused by a lost segment that did not update the context properly. The delta of the current segment is then added to the context again on the assumption that the lost segment contained the same delta as the current. By decompressing and computing the TCP checksum again, the decompressor checks if the repair succeeded or if the delta should be applied once more.
減圧装置は、適切に文脈をアップデートしないかどうか決定するためにTCPチェックサムを計算するかもしれません。 チェックサムが失敗するなら、適切に文脈をアップデートしなかった無くなっているセグメントによって誤りが引き起こされると思われます。 そして、現在のセグメントのデルタは再び文脈に無くなっているセグメントが電流と同じデルタを含んだという前提で追加されます。 減圧と再びTCPチェックサムを計算することによって、減圧装置は、修理が成功したかどうか、またはデルタがもう一度適用されるべきであるかどうかチェックします。
Analysis of traces of various TCP bulk transfers show that applying the delta of the current segment one or two times will repair the context for between 83 and 99 per cent of all single-segment losses in the data stream. For the acknowledgment stream, the success rate is smaller due to the delayed ack mechanism of TCP. The "twice" mechanism repairs the context for 53 to 99 per cent of the losses in the acknowledgment stream. A sophisticated implementation of this idea would determine whether the TCP stream is an acknowledgment or data stream and determine the segment size by observing the stream of full and compressed headers. Trying deltas that are small multiples of the segment size will result in even higher rates of successful repairs for acknowledgment streams.
大量が移すTCPがデータ・ストリームですべてのただ一つのセグメントの損失の83〜99パーセント文脈を修理するのを現在のセグメント1か2時間のデルタがそうするその適用を示している様々の跡の分析。 承認の流れにおいて、成功率はTCPの遅れたackメカニズムのために、よりわずかです。 「二度」というメカニズムは承認の流れで損失の53〜99パーセント文脈を修理します。 この考えの洗練された実現は、TCPの流れが承認かそれともデータ・ストリームであるかを決定して、完全で圧縮されたヘッダーの流れを観測することによって、セグメントサイズを決定するでしょう。 セグメントサイズのわずかな倍数である骨の折れるデルタは承認の流れのためのうまくいっている修理のさらに高い速度をもたらすでしょう。
10.2. Header Requests
10.2. ヘッダー要求
The relatively low success rate for the "twice" algorithm for TCP acknowledgment streams calls for an additional mechanism for repairing the context at the decompressor. When the decompressor fails to repair the context after a loss, the decompressor may optionally request a full header from the compressor. This is possible on links where the decompressor can identify the compressor and send packets to it.
TCP承認の流れのための「二度」というアルゴリズムのための比較的低い成功率は、減圧装置で文脈を修理するために追加メカニズムを求めます。 減圧装置が損失の後に文脈を修理しないと、減圧装置はコンプレッサーから完全なヘッダーを任意に要求するかもしれません。 これは減圧装置がコンプレッサーを特定して、パケットをそれに送ることができるリンクで可能です。
On such links, a decompressor may send a CONTEXT_STATE packet back to the compressor to indicate that one or more contexts are invalid. A decompressor SHOULD NOT transmit a CONTEXT_STATE packet every time a compressed packet refers to an invalid context, but instead should limit the rate of transmission of CONTEXT_STATE packets to avoid flooding the reverse channel. A CONTEXT_STATE packet can indicate that several contexts are out of date, this technique SHOULD be used instead of sending several separate packets. The following diagram shows the format of a CONTEXT_STATE packet.
そのようなリンクの上では、減圧装置は、1つ以上の文脈が無効であることを示すためにCONTEXT_州パケットをコンプレッサーに送り返すかもしれません。 SHOULD NOTが避けるために逆のチャンネルをあふれさせながら圧縮されたパケットが無効の文脈を示すときはいつも、CONTEXT_州パケットを伝えますが、代わりにCONTEXT_州パケットのトランスミッションの速度を制限するはずである減圧装置。 CONTEXT_州パケットは、いくつかの関係が時代遅れであることを示すことができます、このテクニックSHOULD。いくつかの別々のパケットを送ることの代わりに、使用されてください。 以下のダイヤグラムはCONTEXT_州パケットの書式を示しています。
Degermark, et. al. Standards Track [Page 37] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[37ページ]。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| TCP header request = 3 |
+---+---+---+---+---+---+---+---+
| CID count |
+---+---+---+---+---+---+---+---+
| CID |
+---+---+---+---+---+---+---+---+
| CID |
+---+---+---+---+---+---+---+---+
...
+---+---+---+---+---+---+---+---+
| CID |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | TCPヘッダー要求=3| +---+---+---+---+---+---+---+---+ | CIDは数えます。| +---+---+---+---+---+---+---+---+ | Cid| +---+---+---+---+---+---+---+---+ | Cid| +---+---+---+---+---+---+---+---+ ... +---+---+---+---+---+---+---+---+ | Cid| +---+---+---+---+---+---+---+---+
The first octet is a type code to allow the CONTEXT_STATE packet type to be shared for other compression protocols that are (see [CRTP]) or may be defined in parallel with this one. When used for TCP header requests the type code has the value 3, and the remainder of the packet is a sequence of CIDs preceded by a one-octet count of the number of CIDs.
最初の八重奏は、CONTEXT_州パケットタイプが他の圧縮プロトコル([CRTP]を見る)のために共有されるのを許容するタイプコードであるかこれと平行して定義されるかもしれません。 TCPヘッダー要求に使用されると、タイプコードには、値3があります、そして、パケットの残りはCIDsの数の1八重奏のカウントで先行されたCIDsの系列です。
On receipt of a CONTEXT_STATE packet, the compressor MUST mark the CIDs invalid to ensure that the next packet emitted in those packet streams are FULL_HEADER or COMPRESSED_TCP_NODELTA packets.
CONTEXT_州パケットを受け取り次第、コンプレッサーは、それらのパケットの流れで放たれた次のパケットがFULL_HEADERであることを保証するために無効のCIDsかCOMPRESSED_TCPが_NODELTAパケットであるとマークしなければなりません。
Header requests are an optimization, so loss of a CONTEXT_STATE packet does not affect the correct operation of TCP header compression. When a CONTEXT_STATE packet is lost, eventually a new one will be transmitted or TCP will timeout and retransmit. The big advantage of using header requests is that TCP acknowledgment streams can be repaired after a roundtrip-time over the lossy link. This will typically avoid a TCP timeout and unnecessary retransmissions. The lower packet loss rate due to smaller packets will then result in higher throughput because the TCP window can grow larger between losses.
ヘッダー要求が最適化であるので、CONTEXT_州パケットの損失はTCPヘッダー圧縮の正しい操作に影響しません。 CONTEXT_州パケットが結局無くなるとき、新しいものが伝えられるか、TCPはタイムアウトを望んでいて、再送します。 ヘッダー要求を使用する大きい利点は損失性がリンクする往復のタイム・オーバーの後にTCP承認の流れを修理できるということです。 これはTCPタイムアウトと不要な「再-トランスミッション」を通常避けるでしょう。 そして、TCPの窓が損失の間で大きくなることができるので、より小さいパケットによる低いパケット損失率は、より高いスループットをもたらすでしょう。
11. Links that reorder packets
11. その追加注文パケットをリンクします。
Some links reorder packets, for example multi-hop radio links that use deflection routing to route around congested nodes. Packets routed different ways can then arrive at the destination in a different order than they were sent.
或るものは追加注文パケット、例えば鬱血したノードの周りで発送する偏向ルーティングを使用するマルチホップラジオリンクをリンクします。 発送された異なった道がそしてときにそうすることができるパケットはそれらを送ったより異なったオーダーにおける目的地に到着します。
Degermark, et. al. Standards Track [Page 38] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[38ページ]。
11.1. Reordering in non-TCP packet streams
11.1. 非TCPパケットの流れでは、Reorderingします。
Compressed non-TCP headers do not change the context, and neither do full headers that refresh it. There can be problems only when a full header that changes the context arrives out of order. There are two cases:
圧縮された非TCPヘッダーは文脈を変えません、そして、それをリフレッシュする完全なヘッダーがもそうしません。 文脈を変える完全なヘッダーが故障していた状態で到着するときだけ、問題があることができます。 2つのケースがあります:
- A packet with a full header with generation G arrives *after*
a packet with a compressed header with generation G. This case
is covered by rule b) ii) in section 9.
- **Thisがケースに入れる世代G.がある圧縮されたヘッダーがあるパケットがセクション9で規則b)ii)で覆われていた後に世代Gがある完全なヘッダーがあるパケットは到着します。
- A packet with a full header with generation G arrives *before*
a packet with a compressed header with generation G-1 (modulo
64). The decompressor MAY then keep both versions of the
context around for a while to be able to decompress subsequent
compressed headers with generation G-1 (modulo 64). The old
context MUST be discarded after MIN_WRAP seconds.
- 世代Gがある完全なヘッダーがあるパケットは到着します。世代第一部(法64)がある圧縮されたヘッダーがある*aパケットの前の*。 そして、減圧装置は、世代第一部(法64)と共にその後の圧縮されたヘッダーを減圧できるようにしばらく、文脈の両方のバージョンを置くかもしれません。 MIN_WRAP秒以降に古い背景を捨てなければなりません。
11.2. Reordering in TCP packet streams
11.2. TCPパケットの流れでは、Reorderingします。
A compressor may avoid sending COMPRESSED_TCP headers and only send COMPRESSED_TCP_NODELTA headers when there is reordering over the link. Compressed headers will typically be 17 octets with that method, significantly larger than the usual 4-7 octets.
リンクの上に再命令があるときだけ、コンプレッサーは、COMPRESSED_TCPヘッダーを送るのを避けて、COMPRESSED_TCP_NODELTAヘッダーを送るかもしれません。 圧縮されたヘッダーは普通の4-7の八重奏よりかなり大きいその方法をもって通常17の八重奏になるでしょう。
To achieve better compression rates the following method, adding only two octets to the compressed header for a total of 6-9 octets, may be used. A packet sequence number, incremented by one for every packet in the TCP stream, is then associated with each compressed and full header. This allows the decompressor to place the packets in the correct sequence and apply their deltas to the context in the correct order. A simple sliding window scheme is used to place the packets in the correct order.
より良い圧縮率を達成するために、合計6-9の八重奏のために圧縮されたヘッダーに2つの八重奏だけを加えて、以下の方法は使用されるかもしれません。 TCPの流れで各パケットあたり1つ増加されたパケット一連番号はその時、それぞれの圧縮されて完全なヘッダーに関連しています。 これで、減圧装置は、正しい系列にパケットを置いて、正しいオーダーでそれらのデルタを文脈に適用します。 簡単な引窓計画は、正しいオーダーにパケットを置くのに使用されます。
Two octets are needed for the packet sequence numbers. One octet gives only 256 sequence numbers. In a sliding window scheme the window should be no larger than half of the sequence number space, so packets can not arrive more than 127 positions out-of-sequence. This is equivalent to a delay of 260 ms on 2 Mbit/s links with 512 octet segments. Delays of that order are not uncommon over wide-area Internet connections. However, two octets giving 2^16 = 65536 values should be sufficient.
2つの八重奏がパケット一連番号に必要です。 1つの八重奏が256の一連番号だけを与えます。 引窓計画では、窓が一連番号スペースの半分より127位置より大きいはずがないので、パケットは順序が狂って到着できません。 これは512の八重奏セグメントとの2個のメガビット/sリンクの上の260msの遅れに同等です。 そのオーダーの遅れは広い領域インターネット接続の上で珍しくはありません。 しかしながら、2^16 = 65536の値を与える2つの八重奏が十分であるべきです。
Full TCP/IP headers will only have space for one octet of sequence number when there is no tunneling. It is not feasible to increase the size of full headers since the packet size might be optimized for the MTU of the link. Therefore only the least significant octet of the packet sequence number can be placed in such full headers. We believe
トンネルを堀ってはいけないときだけ、完全なTCP/IPヘッダーには、一連番号の1つの八重奏のためのスペースがあるでしょう。 パケットサイズがリンクのMTUのために最適化されるかもしれないので、完全なヘッダーのサイズを増加させるのは可能ではありません。 したがって、パケット一連番号の最も重要でない八重奏しかそのような完全なヘッダーに置くことができません。 私たちは信じています。
Degermark, et. al. Standards Track [Page 39] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[39ページ]。
that such full headers can be positioned correctly frequently enough with only the least significant octet of the packet sequence number available.
パケット一連番号の最も重要でない八重奏だけが利用可能な状態で十分頻繁に正しくそのような完全なヘッダーを置くことができます。
The packet sequence number zero MUST be skipped over. Avoiding zero takes care of a problem that can occur when the TCP window scale option is used to enlarge the TCP window. When exactly 2^16 octets of TCP data is lost, a compressed header will be decompressed incorrectly without being detected by the TCP checksum. TCP segment sizes are often a power of two. So by using a packet sequence number space that is not a power of two either the TCP sequence number or the packet sequence number will differ when 2^16 octets are lost. Whenever a compressor sees the window scale option on a SYN segment, it MUST use packet sequence numbers when subsequently compressing that packet stream.
パケット一連番号ゼロは飛ばされなければなりません。ゼロを避けると、TCP窓のスケールオプションがTCPの窓を拡大するのに使用されるとき起こることができる問題は世話をされます。 まさにTCPデータの2つの^16八重奏が無くなるとき、TCPチェックサムによって検出されないで、圧縮されたヘッダーは不当に減圧されるでしょう。 しばしばTCPセグメントサイズは2のパワーです。 それで、2のパワーでないパケット一連番号スペースを使用することによって、2つの^16八重奏が無くなるとき、TCP一連番号かパケット一連番号のどちらかが異なるでしょう。 次にそのパケットの流れを圧縮するとき、コンプレッサーがSYNセグメントで窓のスケールオプションを見るときはいつも、それはパケット一連番号を使用しなければなりません。
In compressed TCP headers the two octet packet sequence number MUST be placed immediately after the TCP Checksum. See section 5.3 for placement of packet sequence numbers in full headers.
圧縮されたTCPヘッダーに、TCP Checksum直後2八重奏パケット一連番号を置かなければなりません。 完全なヘッダーのパケット一連番号のプレースメントに関してセクション5.3を見てください。
12. Hooks for additional header compression
12. 追加ヘッダー圧縮のためのフック
The following hook is supplied to allow additional header compression schemes for headers on top of UDP. The initial chain of subheaders is then compressed as described here, and the other header compression scheme is applied to the header above the UDP header. An example of such additional header compression is Compressed RTP by Casner and Jacobson [CRTP]. To allow some error detection, such schemes typically need a sequence number that may need to be passed in full headers as well as compressed UDP headers.
UDPの上にヘッダーの追加ヘッダー圧縮技術を許容するために以下のフックを供給します。 次に、「副-ヘッダー」の初期のチェーンはここで説明されるように圧縮されます、そして、もう片方のヘッダー圧縮技術はUDPヘッダーの上のヘッダーに適用されます。 そのような追加ヘッダー圧縮に関する例はCasnerとジェーコブソン[CRTP]によるCompressed RTPです。 何らかの誤り検出を許すために、そのような計画は圧縮されたUDPヘッダーと同様に完全なヘッダーで通過される必要があるかもしれない一連番号を通常必要とします。
The D-bit and Data octet (see section 6) provides the necessary mechanism. When a sequence number, say, needs to be passed in a FULL_HEADER or COMPRESSED_NON_TCP header, the D-bit is set and the sequence number is placed in the Data field. The decompressor must then extract and make the Data field available to the additional header compression scheme.
D-ビットとData八重奏(セクション6を見る)は必要なメカニズムを提供します。 たとえば、一連番号が、FULL_HEADERかCOMPRESSED_NON_TCPヘッダーで通過される必要があるとき、D-ビットは設定されます、そして、一連番号はData分野に置かれます。 減圧装置で、次に、Data野原は、追加ヘッダー圧縮技術に利用可能に抽出して、ならなければなりません。
Use of additional header compression schemes like CRTP must be negotiated. The D-bit and Data octet mechanism must automatically be enabled whenever use of additional header compression schemes has been negotiated.
追加ヘッダー圧縮の使用はCRTPを交渉しなければならないように計画されます。 追加ヘッダー圧縮技術の使用が交渉されたときはいつも、自動的にD-ビットとData八重奏メカニズムを可能にしなければなりません。
Degermark, et. al. Standards Track [Page 40] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[40ページ]。
13. Demultiplexing
13. 逆多重化
For each link layer, there must be a document specifying how the various packet types used by IP header compression is indicated. Such a document exists for PPP [PPP-HC]. This section gives OPTIONAL guidelines on how packet types may be indicated by a specific link- layer.
各リンクレイヤのために、IPヘッダー圧縮で使用される様々なパケットタイプがどう示されるかを指定するドキュメントがあるに違いありません。 そのようなドキュメントはPPP[PPP-HC]のために存在しています。 このセクションはパケットタイプが特定のリンク層のそばでどう示されるかもしれないかに関するガイドラインをOPTIONALに与えます。
It is necessary to distinguish packets with regular IPv4 headers, regular IPv6 headers, full IPv6 packets, full IPv4 packets, compressed TCP packets, compressed non-TCP packets, and CONTEXT_STATE packets.
レギュラーのIPv4ヘッダー、レギュラーのIPv6ヘッダー、完全なIPv6パケット、完全なIPv4パケット、圧縮されたTCPパケット、圧縮された非TCPパケット、およびCONTEXT_州パケットでパケットを区別するのが必要です。
The decision to use a distinct ethertype (or equivalent) for IPv6 has already been taken, which means that link-layers must be able to indicate that a packet is an IPv6 packet.
IPv6に、異なったethertype(または、同等物)を使用するという決定(リンクレイヤが、パケットがIPv6パケットであることを示すことができなければならないことを意味する)は既にかかりました。
IP header compression requires that the link-layer implementation can indicate four kinds of packets: COMPRESSED_TCP for format a) in section 6, COMPRESSED_TCP_NODELTA for format b), COMPRESSED_NON_TCP for formats c) and d), and CONTEXT_STATE as described in section 11.2. It is also desirable to indicate FULL_HEADERS at the link layer.
IPヘッダー圧縮は、リンクレイヤ実現が4種類のパケットを示すことができるのを必要とします: COMPRESSED_のCOMPRESSED_のセクション6の形式a)のためのCOMPRESSED_TCP、形式b)のためのTCP_NODELTA、形式c)とd)のためのNON_TCP、およびセクション11.2で説明されるCONTEXT_州。 また、リンクレイヤでFULL_HEADERSを示すのも望ましいです。
Full headers can be indicated by setting the first bit of the Version field in a packet indicated to be an IPv6 packet. In addition, one bit of the Version field is used to indicate if the first subheader is an IPv6 or an IPv4 header, and one bit is used to indicate if this full header carries a TCP CID or a non-TCP CID. The first four bits are encoded as follows:
IPv6パケットになるように示されたパケットにおける、バージョン分野の最初のビットを設定することによって、完全なヘッダーを示すことができます。 さらに、バージョン分野の1ビットは最初の「副-ヘッダー」がIPv6かそれともIPv4ヘッダーであるかを示すのに使用されます、そして、1ビットは、この完全なヘッダーがTCP CIDか非TCP CIDを運ぶかどうかを示すのに使用されます。 最初の4ビットは以下の通りコード化されます:
Version Meaning
------- -------
バージョン意味------- -------
0110 regular IPv6 header
0110年のレギュラーのIPv6ヘッダー
1T*0 T=1 indicates a TCP header, T=0 indicates a non-TCP header
1*V0 V=1 indicates a IPv6 header, V=0 indicates a IPv4 header
1T*0T=1はTCPヘッダーを示して、T=0は、非TCPヘッダー1*V0 V=1がIPv6ヘッダーを示すのを示して、V=0はIPv4ヘッダーを示します。
If a link-layer cannot indicate the packet types for the compressed headers or CONTEXT_STATE, packet types that cannot be indicated could start with an octet indicating the packet type, followed by the header.
リンクレイヤが、パケットが圧縮されたヘッダーかCONTEXT_州のためにタイプされるのを示すことができないなら、示すことができないパケットタイプはヘッダーによってついて来られたパケットタイプを示す八重奏から始まるかもしれません。
Degermark, et. al. Standards Track [Page 41] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[41ページ]。
First octet Type of compressed header
----------- -------------------------
圧縮されたヘッダーの最初の八重奏Type----------- -------------------------
0 COMPRESSED_TCP
1 COMPRESSED_TCP_NODELTA
2 COMPRESSED_NON_TCP
3 CONTEXT_STATE
0 圧縮された_TCP1は_非_のTCP3文脈_が述べるTCP_NODELTA2の圧縮された_を圧縮しました。
The currently assigned CONTEXT_STATE type values are
現在割り当てられたCONTEXT_州タイプ値はそうです。
Value Type Reference
----- ----- ----------
0 Reserved -
1 IP/UDP/RTP w. 8-bit CID [CRTP]
2 IP/UDP/RTP w. 16-bit CID [CRTP]
3 TCP header request Section 10.2
値のタイプ参照----- ----- ---------- 0 予約されました--1IP/UDP/RTP w。 8ビットのCID[CRTP]2IP/UDP/RTP w。 16ビットのCID[CRTP]3TCPヘッダー要求セクション10.2
14. Configuration Parameters
14. 設定パラメータ
Header compression parameters are negotiated in a way specific to the link-layer implementation. Such procedures for link-layer xxx needs to be specified in a document "IP header compression over xxx". Such a document exists for PPP [PPP-HC].
ヘッダー圧縮パラメタはリンクレイヤ実現に特定の方法で交渉されます。 xxxが「xxxの上のIPヘッダー圧縮」というドキュメントで指定されるために必要とするリンクレイヤのためのそのような手順。 そのようなドキュメントはPPP[PPP-HC]のために存在しています。
The following parameter is fixed for all implementations of this header compression scheme.
以下のパラメタはこのヘッダー圧縮技術のすべての実現のために修理されています。
MIN_WRAP - minimum time of generation value wrap around
MIN_WRAP--世代値のおよそ包装の最小の時間
3 seconds.
3秒。
The following parameters can be negotiated between the compressor and decompressor. If not negotiated their values must be as specified by DEFAULT.
コンプレッサーと減圧装置の間で以下のパラメタを交渉できます。 交渉されないなら、DEFAULTによって指定されるようにそれらの値があるに違いありません。
F_MAX_PERIOD - Largest number of compressed non-TCP headers that
may be sent without sending a full header.
F_マックス_PERIOD--完全なヘッダーを送らないで送られるかもしれない圧縮された非TCPヘッダーの最多数。
DEFAULT is 256
DEFAULTは256歳です。
F_MAX_PERIOD must be at least 1 and at most 65535.
F_マックス_PERIODは少なくとも1と高々65535であるに違いありません。
F_MAX_TIME - Compressed headers may not be sent more than
F_MAX_TIME seconds after sending last full header.
F_マックス_タイム誌--最後の完全なヘッダーを送ったマックス_タイム誌秒後に、F_以上は圧縮されたヘッダーに送られないかもしれません。
DEFAULT is 5
DEFAULTは5歳です。
Degermark, et. al. Standards Track [Page 42] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[42ページ]。
F_MAX_TIME must be at least 1 and at most 255.
F_マックス_タイム誌は、少なくとも1と高々255であるに違いありません。
NOTE: F_MAX_PERIOD and F_MAX_TIME should be lower when it is
likely that a decompressor loses its state.
以下に注意してください。 _Fマックス_PERIODと_Fマックス_タイム誌は低くあるべきです。減圧装置が状態を失いそうなとき、低くいてください。
MAX_HEADER - The largest header size in octets that may
be compressed.
マックス_HEADER--圧縮されるかもしれない八重奏で最も大きいヘッダーサイズ。
DEFAULT is 168 octets, which covers
DEFAULTは168の八重奏、どのカバーであるか。
- Two IPv6 base headers
- A Keyed MD5 Authentication Header
- A maximum-sized TCP header
- 2個のIPv6ベースヘッダー--Keyed MD5 Authentication Header--最大サイズのTCPヘッダー
MAX_HEADER must be at least 60 octets and
at most 65535 octets.
マックス_HEADERは少なくとも60の八重奏と高々65535の八重奏であるに違いありません。
TCP_SPACE - Maximum CID value for TCP.
TCP_SPACE--TCPに、最大のCID値。
DEFAULT is 15 (which gives 16 CID values)
DEFAULTは15歳です。(16のCID値を与えます)
TCP_SPACE must be at least 3 and at most 255.
TCP_SPACEは少なくとも3と高々255歳であるに違いありません。
NON_TCP_SPACE - Maximum CID value for non-TCP.
NON_TCP_SPACE--非TCPに、最大のCID値。
DEFAULT is 15 (which gives 16 CID values)
DEFAULTは15歳です。(16のCID値を与えます)
NON_TCP_SPACE must be at least 3 and at most 65535.
NON_TCP_SPACEは少なくとも3と高々65535であるに違いありません。
EXPECT_REORDERING - The mechanisms in section 11 are used.
EXPECT_REORDERING--セクション11のメカニズムは使用されています。
DEFAULT no.
DEFAULT No.
15. Implementation Status
15. 実装状態
A prototype using UDP as the link layer has been operational since March 1996. A NetBSD implementation for PPP has been operational since October 1996.
1996年3月以来リンクレイヤとしてUDPを使用するプロトタイプは操作上です。 1996年10月以来PPPのための386BSD派生のOS実装は操作上です。
Degermark, et. al. Standards Track [Page 43] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[43ページ]。
16. Acknowledgments
16. 承認
This protocol uses many ideas originated by Van Jacobson in the design of header compression for TCP/IP over slow-speed links [RFC- 1144]. It has benefited from discussions with Stephen Casner and Carsten Bormann.
このプロトコルはTCP/IPに遅い速度リンク[RFC1144]の上にヘッダー圧縮のデザインにおけるヴァン・ジェーコブソンによって溯源された多くの考えを使用します。 それはスティーブンCasnerとカルステン・ボルマンとの議論の利益を得ました。
We thank Craig Partridge for pointing out a problem that can occur when the TCP window scale option is used. A solution to this problem relying on the packet sequence numbers used for reordering is described in section 11.2.
私たちは、TCP窓のスケールオプションが使用されているとき起こることができる問題を指摘して頂いて、クレイグPartridgeに感謝します。 解決はセクション11.2で再命令するのに使用されるパケット一連番号を当てにすることにおけるこの問題に説明されます。
17. Security Considerations
17. セキュリティ問題
The compression protocols in this document run on top of a link-layer protocol. The compression protocols themselves introduce no new additional vulnerabilities beyond those associated with the specific link-layer technology being used.
圧縮プロトコルはリンク層プロトコルの上で本書では稼働しています。 圧縮プロトコル自体は使用される特定のリンクレイヤ技術に関連づけられたものを超えてどんな新しい追加脆弱性も導入しません。
Denial-of-service attacks are possible if an intruder can introduce (for example) bogus Full Header packets onto the link. However, an intruder having the ability to inject arbitrary packets at the link- layer in this manner raises additional security issues that dwarf those related to the use of header compression.
侵入者が(例えば)にせのFull Headerパケットをリンクに導入できるなら、サービス不能攻撃は可能です。 しかしながら、リンク層で任意のパケットを注入する能力を持っている侵入者はこの様にヘッダー圧縮の使用に関連するものを小さくする追加担保問題を提起します。
We advise implementors against identifying packet streams with the aid of information that is encrypted, even if such information happens to be available to the compressor. Doing so may expose traffic patterns.
私たちは暗号化された情報の援助とパケットストリームを同一視しないように作成者にアドバイスします、そのような情報がたまたまコンプレッサーに利用可能であってもさえ。 そうするのは、トラフィックがパターンであると暴露するかもしれません。
Degermark, et. al. Standards Track [Page 44] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[44ページ]。
18. Authors' Addresses
18. 作者のアドレス
Mikael Degermark Department of Computer Science and Electrical Engineering Lulea University of Technology SE-971 87 Lulea, Sweden
マイケルデーゲルマルクコンピュータサイエンス学部と技術SE-971 87ルーレオ(スウェーデン)の電気工学ルーレオ大学
Phone: +46 920 91188 Fax: +46 920 72831 Mobile: +46 70 833 8933 EMail: micke@sm.luth.se
以下に電話をしてください。 +46 920 91188Fax: +46 920 72831 モバイル: +46 70 833 8933はメールされます: micke@sm.luth.se
Bjorn Nordgren CDT/Telia Research AB Aurorum 6 S-977 75 Lulea, Sweden
ビヨンNordgren CDT/Telia研究AB Aurorum6秒間-977 75ルーレオ(スウェーデン)
Phone: +46 920 75400 Fax: +46 920 75490 EMail: bcn@lulea.trab.se, bcn@cdt.luth.se
以下に電話をしてください。 +46 920 75400Fax: +46 920 75490 メール: bcn@lulea.trab.se 、bcn@cdt.luth.se
Stephen Pink Department of Computer Science and Electrical Engineering Lulea University of Technology SE-971 87 Lulea, Sweden
スティーブンPinkのコンピュータサイエンス学部と技術SE-971 87ルーレオ(スウェーデン)の電気工学ルーレオ大学
Phone: +46 920 752 29 Fax: +46 920 728 31 Mobile: +46 70 532 0007 EMail: steve@sm.luth.se
以下に電話をしてください。 +46 920 752、29Fax: +46 920 728 31モバイル: +46 70 532 0007はメールされます: steve@sm.luth.se
Degermark, et. al. Standards Track [Page 45] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[45ページ]。
19. References
19. 参照
[RFC-768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC-768] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC-791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC-793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC-793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC-1144] Jacobson, V., "Compressing TCP/IP Headers for Low-
Speed Serial Links", RFC 1144, February 1990.
1990年2月の[RFC-1144]ジェーコブソン対「低い速度連続のリンクへのTCP/IPヘッダーを圧縮すること」でのRFC1144
[RFC-1553] Mathur, A. and M. Lewis, "Compressing IPX Headers
Over WAN Media (CIPX)", RFC 1553, December 1993.
[RFC-1553] マートゥルとA.とM.ルイス、「青白いメディア(CIPX)の上にIPXヘッダーを圧縮します」、RFC1553、1993年12月。
[RFC-1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD
2, RFC 1700, October 1994. See also:
http://www.iana.org/numbers.html
[RFC-1700] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。 参照: http://www.iana.org/numbers.html
[RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[RFC-2402] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Protocol (ESP)", RFC 2406, November 1998.
[RFC-2406]ケントとS.とR.アトキンソン、「セキュリティがプロトコル(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[RFC-1828] Metzger, W., "IP Authentication using Keyed MD5", RFC
1828, August 1995.
w.[RFC-1828]メッツガー、「IP認証使用は1995年8月にMD5"、RFC1828を合わせました」。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol,
Version 6 (IPv6) Specification", RFC 2460, December
1998.
[IPv6]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification.", RFC 2463, December 1998.
[ICMPv6] コンタ、A.、およびS.デアリング、「インターネットへのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)はバージョン6(IPv6)仕様を議定書の中で述べる」、RFC2463(1998年12月)
[RFC-2004] Perkins, C., "Minimal Encapsulation within IP", RFC
2004, October 1996.
[RFC-2004] パーキンス、C.、「IPの中の最小量のカプセル化」、RFC2004、1996年10月。
[CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508,
February 1999.
[CRTP]Casner、S.、およびRFC2508、1999年2月対「低速連続のリンクへのIP/UDP/RTPヘッダーを圧縮する」ジェーコブソン
[PPP-HC] Engan, M., Casner, S. and C. Bormann, "IP Header
Compression for PPP", RFC 2509, February 1999.
[ppp-HC] EnganとM.とCasnerとS.とC.ボルマン、「pppのためのIPヘッダー圧縮」、RFC2509、1999年2月。
Degermark, et. al. Standards Track [Page 46] RFC 2507 IP Header Compression February 1999
etデーゲルマルク、アル。 規格はIPヘッダー圧縮1999年2月にRFC2507を追跡します[46ページ]。
20. Full Copyright Statement
20. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. .fi
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。 .fi
Degermark, et. al. Standards Track [Page 47]
etデーゲルマルク、アル。 標準化過程[47ページ]
一覧
スポンサーリンク
