INTERNET-DRAFT Yousuf Saifullah Date: 17 October 2003 Zhigang Liu Expires: 17 April 2004 Nokia Research Center IP Address Compression in Context Replication Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The Context Replication (CR) mechanism [3] for Robust Header Compression (ROHC) uses an existing compression context for creating a new compression context, thus, saves sending some of the header information from the compressor to the decompressor during context initialization. The current CR mechanism could also save sending an IP address from the header information. However, it either sends a whole IP address or doesn't send an IP address. This Internet Draft enhances the CR mechanism by providing an option of sending compressed IP address. Saifullah, Liu [Page 1] INTERNET-DRAFT IP Address Compression in CR 17 October 2003 Table of Contents Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . 1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. IP Address Compression Technique . . . . . . . . . . . . . . . 3 2.1. Compressor Logic . . . . . . . . . . . . . . . . . . . . 4 2.2. Decompressor Logic . . . . . . . . . . . . . . . . . . . 5 3. Protocol Changes . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Intellectual Property Right Notice . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Address Format . . . . . . . . . . . . . . . . . . . 8 A.1. IPv4 Address Structure . . . . . . . . . . . . . . . . . 8 A.2. IPv6 Address Structure . . . . . . . . . . . . . . . . . 8 Saifullah, Liu [Page 2] INTERNET-DRAFT IP Address Compression in CR 17 October 2003 1. Introduction A header compression scheme compresses the header of an IP packet belonging to a context. A context is established between a compressor and its decompressor for a particular packet data flow. A compression scheme usually requires transfer of full header from the compressor to the decompressor to build the context at the decompressor. The ROHC WG is also developing a Context Replication (CR) technique [3] that initializes the context of a new flow by using an existing context (base context) at the decompressor. This allows a new packet flow to build its context using a context of another packet flow without transferring the full header. In this way CR reduces the amount of information transferred for building the context. The current CR proposal only allows either sending a full IP address or not sending an IP address for building a new context. An IP header contains source and destination IP addresses. The structure of IP addresses suggests that there is a repetition of information from one address to another (Appendix A). For example, IPv4 Class B addresses have same 2 out of 4 bytes for the nodes in the same network. Also, IPv6 anycast addresses have same 64 bits for the nodes in a subnetwork, if the subnet prefix is 64 bits. Therefore, there is a potential for sending compressed IP addresses. This draft defines a technique for compressing an IP address using an IP address from the base context. It enhances the CR mechanism by allowing sending of the compressed IP address for building the new context. This enhancement improves header compression efficiency when packet flows carry similar (e.g. same prefix) but not exactly same IP addresses. In particular, the gain can be significant for IPv6 header compression due to the large size (16 bytes) of IPv6 addresses. The IP address compression for replication is designed on top of the proposed CR scheme and does not introduce any change in the base CR mechanism. This draft only describes the procedures and the protocol specific to the IP address compression for replication. It assumes that the reader is familiar with the ROHC and CR mechanisms. 2. IP Address Compression Technique Saifullah, Liu [Page 3] INTERNET-DRAFT IP Address Compression in CR 17 October 2003 2.1. Compressor Logic The compressor performs compression on a source and destination IP address of a new context by using the corresponding source and destination IP address from a base context. Let's assume that an IP address in the base context is called base_addr and the corresponding IP address of a new context is called new_addr. The compressor logic performs two main steps. Step-1: Decision for the compression of new_addr. Step-2: Actual Compression of new_addr using base_addr. Step-1 is done by recognizing the similarity between the base_addr and new_addr. This recognition is implementation dependent, and does not need to be standardized. This draft suggests a bit-wise XOR operation between the two addresses. If the result has: - all zeroes, a Full Match is identified. - zeroes in some of the leading bits, a Prefix Match is identified - zeroes in the trailing bits, a Suffix Match is identified - anything else, No Match is identified In the case of Prefix and Suffix Match, the compressor also evaluates whether the compressed address is smaller than the uncompressed address. Specifically, the number of leading/trailing zeroes should be greater than the overhead to encode the number. The overhead, i.e. the size of the matched length (see format in section 3), is 5 bits for IPv4 and 7 bits for IPv6. Step-2 performs a simple compression method of encoding only the length of the matched bits. The matched length is followed by the unmatched bits. For the Prefix Match, the matched length indicates the leading matched bits. For the Suffix Match, the matched length indicates the trailing matched bits. The compressor sends the type of the match along with the following information, for both the source and destination IP addresses, to the decompressor: - For "Full Match", don't send the new_addr - For "Prefix/Suffix Match", send the compressed new_addr (matched length followed by the unmatched bits) Saifullah, Liu [Page 4] INTERNET-DRAFT IP Address Compression in CR 17 October 2003 - For "No Match", send the uncompressed new_addr 2.2. Decompressor Logic The decompressor, after receiving a packet for context initialization using CR mechanism, determines the type of match for the source and destination IP addresses. Based on the type of match, it uses the base_addr from the referred base context to generate new_addr for the new context. 3. Protocol Changes The CR mechanism has defined an IR-REPLICATE packet for sending reduced header information during context initialization. The compressed IP address is also sent in the IR-REPLICATE packet. The packet contains a set of indicator flags to indicate the header fields present in the packet. The format of the IR-REPLICATE packet is still under determination. This section describes the protocol changes using the formats described in [3], which makes use of indicator flags. The proposed changes can be incorporated into any other format, e.g. indicator code format. The compressor should define flags in the IR-REPLICATE header to send type of Match for the decompressor. It uses two bits each for the source and the destination IP addresses. The bits are called Source Address Match (SAM) for the source IP address, and Destination Address Match (DAM) for the destination IP address. * SAM/DAM = 00 - No Match; IR-REPLICATE carries full source/destination IP address * SAM/DAM = 01 - Full Match; IR-REPLICATE carries no source/destination IP address * SAM/DAM = 10 - Prefix Match; IR-REPLICATE carries compressed source/destination IP address * SAM/DAM = 11 - Suffix Match; IR-REPLICATE carries compressed source/destination IP address A compressed source/destination IP address is carried in the following format: Saifullah, Liu [Page 5] INTERNET-DRAFT IP Address Compression in CR 17 October 2003 +------------+---------------+ | matched-len| unmatched-bits| +------------+---------------+ * matched-len: the length, in units of bits, of the prefix/suffix that are same between the base_addr and new_addr. The size of this field is 5 bits for IPv4 and 7 bits for IPv6. The compressed IP address is only sent when the number of matched bits is greater than the matched-len size. Therefore, matched-len can be offset by 5 (IPv4) or 7 (IPv6). In other words, for IPv4 a value of 0 means 6 bits match, a value of 1 means 7 bits match, and so on. * unmatched-bits: the (N - matched-len) bits in new_addr, where N is the total length of an IP address in units of bits. N = 32 for IPv4 and N = 128 for IPv6. These are leading bits in the case of suffix match, and are trailing bits in the case of prefix match. This field could be followed by some padding bits for the byte alignment. The formatting should also consider the available unused bits and byte alignment in the IR-REPLICATE packet for further compacting the compressed IP address. For example, 5 bits of the IPv4 matched-len field could be placed in a field which has 5 unused bits. Also, the matched-len could be coded in bytes instead of bits. In this case, we need only 2 bits for IPv4 and 4 bits for IPv6. These bits could be placed in a field which has 2 or 4 unused bits. 4. Security Considerations This draft does not bring any new security considerations for the ROHC mechanisms including CR. 5. Intellectual Property Right Notice Nokia has a pending patent applications that may be relevant to this draft. Please refer to for more information. Saifullah, Liu [Page 6] INTERNET-DRAFT IP Address Compression in CR 17 October 2003 6. References [1] R. Hinden, S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC3513, April 2003 [2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [3] Ghyslain Pelletier, "RObust Header Compression (ROHC): Context Replication for ROHC Profiles", Internet Draft, June 2003. 7. Authors' Addresses Yousuf Saifullah Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 894-6966 E-mail: yousuf.saifullah@nokia.com Zhigang Liu Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 894-5935 E-mail: zhigang.c.liu@nokia.com Saifullah, Liu [Page 7] INTERNET-DRAFT IP Address Compression in CR 17 October 2003 Appendix A. Address Format This appendix describes the format of IPv4 and IPv6 addresses, so that the reader could get familiar with the redundancy in an IP address. The details of the formats are described in [1] and [2]. A.1. IPv4 Address Structure The IPv4 address is usually expressed as four decimal numbers, each representing a byte, separated by periods. IPv4 defines an address format based on the following four classes. The first few bits are used for indicating the class type: * Class A 0 Network address (7 bits) Local address (24 bits). Class A addresses are for large networks with many devices. * Class B 10 Network address (14 bits) Local address (16 bits). Class B addresses are for medium-sized networks. * Class C 110 Network address (21 bits) Local address (8 bits). Class C addresses are for small networks (fewer than 256 devices). * Class D 1110 Multicast address (28 bits). A.2. IPv6 Address Structure IPv6 has 16 byte addresses. It has three types of addressing: unicast, anycast, and multicast. * Unicast address is an identifier for a single interface. | n bits | 128-n bits | +---------------+----------------+ | subnet prefix | interface ID | +---------------+----------------+ The subnet prefix field identifies a subnetwork. The interface ID identifies an interface on a link, they are unique for a subnet prefix. There are many derivative formats of the unicast address for different uses as explained in [2], e.g. global unicast address. All of them have potential for having leading bits of the address similar to another. * Anycast address is an address that is assigned to a set of interfaces, with the property that a packet sent to an anycast address is routed to the "nearest" interface having that Saifullah, Liu [Page 8] INTERNET-DRAFT IP Address Compression in CR 17 October 2003 address. The Subnet-Router anycast address is as follows: | n bits | 128-n bits | +---------------+----------------+ | subnet prefix | 00000000000000 | +---------------+----------------+ * Multicast Address is an address for a group of interfaces (typically on different nodes). An interface may belong to any number of multicast groups. Multicast Addresses have the following format: | 8 | 4 | 4 | 112 bits | +------ -+----+----+----------------------------------------+ |11111111|flgs|scop| group ID | +--------+----+----+----------------------------------------+ 11111111 at the start of the address indicates a multicast address. flgs identifies whether the address is a permanently-assigned or a non-permanently-assigned by the Internet Assigned Number Authority (IANA) scop is a multicast scope value used to limit the scope of the multicast group, in terms of site-local, organization-local, etc. group ID identifies a multicast group. This Internet-Draft expires on April 17, 2003. Saifullah, Liu [Page 9]