Internet DRAFT - draft-saifullah-rohc-ip-addr-comp-context-replication
draft-saifullah-rohc-ip-addr-comp-context-replication
INTERNET-DRAFT Yousuf Saifullah
Date: 17 October 2003 Zhigang Liu
Expires: 17 April 2004 Nokia Research Center
IP Address Compression in Context Replication
<draft-saifullah-rohc-ip-addr-comp-context-replication-00.txt>
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 <http://www.ietf.org/ietf/IPR/Nokia>
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]
