rfc2507.txt
来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,547 行 · 第 1/5 页
TXT
1,547 行
Network Working Group M. DegermarkRequest for Comments: 2507 Lulea University of Technology/SICSCategory: Standards Track B. Nordgren Lulea University of Technology/Telia Research AB S. Pink Lulea University of Technology/SICS February 1999 IP Header CompressionStatus of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.Copyright Notice Copyright (C) The Internet Society (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. 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. 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.....................14Degermark, et. al. Standards Track [Page 1] RFC 2507 IP Header Compression February 1999 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.................................47Degermark, et. al. Standards Track [Page 2] RFC 2507 IP Header Compression February 19991. Introduction 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. * 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. 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. * 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. * 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 100Degermark, et. al. Standards Track [Page 3] RFC 2507 IP Header Compression February 1999 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. 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%. * 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. 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. 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. 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 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. 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.2. Terminology 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. Subheader An IPv6 base header, an IPv6 extension header, an IPv4 header, a UDP header, or a TCP header. 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 Context identifier (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. 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.⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?