tsvwg Anni. Wei Internet-Draft Lei. zhu Intended status: Informational Huawei Technologies Expires: December 24, 2010 June 22, 2010 Nested Compression in ROHC draft-wei-tsvwg-nested-header-compression-00 Abstract The appearance of wireless technologies in cellular network attracts the attentions to compress at least two layers of nested compression headers. This document describes a nested compression scenario, by coordinating the header fields that have similar functions or even are repeated in layers of nested compressed packet, to reduce processing latency, packet header payload and increase the compression efficiency. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on December 24, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Wei & zhu Expires December 24, 2010 [Page 1] Internet-Draft Nested compression June 2010 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements and Applicability . . . . . . . . . . . . . . . . 4 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 4. Compressor and decompressor . . . . . . . . . . . . . . . . . 6 4.1. Compressor . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Decompressor . . . . . . . . . . . . . . . . . . . . . . . 7 5. Nested compression . . . . . . . . . . . . . . . . . . . . . . 7 5.1. overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Nested compression . . . . . . . . . . . . . . . . . . . . 7 6. CRC Considerations . . . . . . . . . . . . . . . . . . . . . . 11 6.1. CRC in compressed headers . . . . . . . . . . . . . . . . 11 6.2. Discussion of CRC problem in nested compression . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 10. Normative References . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Wei & zhu Expires December 24, 2010 [Page 2] Internet-Draft Nested compression June 2010 1. Introduction In cellular communication system, compression technology is extensively used. The application of compression technology can significantly reduce the use of radio resource and improve the network transmission delay. ROHC technologies are effective way to improve system performance in wireless communication system. The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics. The development of wireless communication technologies leads the nesting header compression to be an appreciate requirement. This document is structured as follows: First, we start by describing the terminology and acronyms used in this document in Section 2, Followed by the requirements and applicability of the nested compression method proposed in this document in Section 3, and then the concept and behavior introduction of compressor and decompression in Section 4. In Section 5 we discuss nested compression scheme in detail. Final discussions are CRC Considerations, security considerations, IANA considerations, and Acknowledgements. 2. Terminology 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 [RFC2119]. 2.1. Terminology Nested Compression: In the same format of an encapsulation data package, add one or more compressed headers out of the compressed headers existed. 2.2. Acronyms CID: Context Identifier CRC: Cyclic Redundancy Check IP: Internet Protocol MSN: Master Sequence Number NACK: Negative Acknowledgment ROHC: Robust Header Compression Wei & zhu Expires December 24, 2010 [Page 3] Internet-Draft Nested compression June 2010 RTP: Real-time Transport Protocol UDP: User Datagram Protocol 3. Requirements and Applicability 3.1. Requirements Modern wireless technologies increase the density of sites and antennas by adding some new intermediate nodes based on the original site. It is the wireless link between these additional intermediate note and the original base station (eNB). The data of downlink reaches base station first and passes through Relay node, and then is transferred to the user equipment by Relay node, upstream is the opposite direction. This approach can improve the quality of the terminal link, therefore enhance the system spectrum efficiency and user data rate. As shown below, intermediate node is between base station and mobile terminal. UE Net node Donor-eNB | ~ ~ ~ \ / ~ ~ ~ \ / | | | +--+ | | | | | | | | | | +--+ | | Picture 1 Intermediate node scenarios The system protocol stack of 3GPP LTE architecture is shown as follows: Wei & zhu Expires December 24, 2010 [Page 4] Internet-Draft Nested compression June 2010 +-------------+ | | +-----------------+ + IP + | \Relay / Tunnel| | | | \ /protocol| + + + +----------+ | | | | UDP | + + + +----------+ | | | | IP | +-------------+ + +----------+ +------+ | PDCP |---|---| PDCP | PDCP |---|---| PDCP | +-------------+ +-----------------+ +------+ | L2 |---|---| L2 | L2 |---|---| L2 | +-------------+ +-----------------+ +------+ | L1 |---|---| L1 | L1 |---|---| L1 | +-------------+ +-----------------+ +------+ Compressor Compressor/Decompressor Decompressor Picture 2 possible protocol stack When data is transferred in a single hop link, it just need header fields of link-layer to guarantee packet be correctly transmitted to next hop. However, header fields in the network layer or above such as IP, UDP, RTP does not work in a single hop, so ROHC in the OSI / ISO protocol stack located between the link layer and network layer, i.e. PDCP layer. There is one ROHC header (IP/UDP/RTP compression header) in encapsulation date without intermediate node: +-------+-------+-------+-------+-----------+-------+ | L1 | MAC |RLC |PDCP |IP/UDP/RTP | Date | +-------+-------+-------+-------+-----------+-------+ Picture 3 encapsulation date with out nested compression However, there are at least two-layer nested ROHC compression header: +----+----+----+----+----------------------+-----------+-----+ |L1 | MAC|RLC |PDCP|IP/UDP/Tunnel-protocol| IP/UDP/RTP|Date | +----+----+----+----+----------------------+-----------+-----+ Wei & zhu Expires December 24, 2010 [Page 5] Internet-Draft Nested compression June 2010 Picture 4 encapsulation date with nested compression In the case of nested compression, the existing technology will only use a specific compression method such as IP / UDP / RTP compression profile or IP / UDP / TUNNEL-PROTOCOL compression profile respectively to compress each protocol header in nested layers. There is no connection between the compression headers. Header fields that have similar functions or even are repeated in layers of nested compression occupy bytes, resulting in vital waste of radio resources. 3.2. Applicability In this document, nested compression program applies to any scenarios with nested ROHC header compression. 4. Compressor and decompressor ROHC is primarily designed to compress the packet stream. Its function entities include the compressor and decompressor. When a new packet stream arrives, the compressor comes into the initialization compression state, the header field information of stream packet is stored in the corresponding context. At the some time, the complete context information is sent to the decompressor. When the compressor detects the receipt of context information at decompressor, compressor will enter the compressed state and start to send compressed packets. After that, every time at sending a packet, context information of the packet stream should be updated. Accordingly, the decompressor save complete context information send by compressor at first, after that, every time at receiving a packet, the decompressor should update the corresponding context information to ensure the preservation is the last context information , so as to make sure the synchronization between the compressor and decompression. In this process, when there is error caused by wireless link, packet loss and other reasons, context information between decompressor and the compressor may be inconsistencies, which cause failure of decompression. CRC arithmetic in ROHC can make sure the context information updated timely and correctly. 4.1. Compressor At the compressor side, ROHC is responsible for handling packet that the network layer submitted to the link layer. In the network layer, each network interface can initiate a number of packet streams. In the ROHC protocol, context information is conceptually kept in a table. The context table is indexed using the CID, which is sent along with compressed headers and feedback information. Packet Wei & zhu Expires December 24, 2010 [Page 6] Internet-Draft Nested compression June 2010 processed by ROHC compressor, removing the long header fields such as IP header field, UDP header field and the RTP header field of the packet submitted by network-layer, while, it add a much shorter length of the ROHC header field in front of the data, and submit it to the link layer for packet encapsulation, and sent to the next node by way of point to point at the network layer. 4.2. Decompressor At the decompressor side, ROHC is responsible for handling packet that the link layer submitted to the network layer. When receives packet of link-layer, the decompressor distinguish different packet streams via each other's network interface and the CID .Then decompressor find context information of the packet stream according to the new ROHC header field, and recovered the original packet, including the IP header field, UDP and RTP header field header fields and so on, and then decompressor re-submit the decompression packet to the network layer. 5. Nested compression 5.1. overview This document describes a nested compression schemes: In the case that need nested compression, coordinating the header fields that have similar functions or even are repeated in layers of nested compression , that is, borrow, and delete some redundant fields (MSN or LSB). At the nested compression process, some header fields in inner compression packet and outer compressed packet can be be used by each other. The process is as follows: the compressor sends data packets to the intermediate node, which includes the inner compression header. When intermediate node receives the packet headers, it adds the outer compression headers, and then removes the duplicate field by coordinating the header fields that have similar functions or even are repeated in layers of nested compression. After that intermediate station sends nested header compression protocol packets to the decompressor. 5.2. Nested compression Nested compression method in this document can be applied to any case that exist the nested compression. In the picture below, UE is compressor, the intermediate station is Decompressor/Compressor , eNB is Decompressor. There are at least two layers of nested protocol header in the intermediate station, inside is IP / UDP / RTP Wei & zhu Expires December 24, 2010 [Page 7] Internet-Draft Nested compression June 2010 compression protocol and its outside is IP / UDP / TUNNEL-PROTOCOL compression protocol. Here we discuss scenario with only one intermediate node. +------------+ +---------------+ |Decompressor| +------------+ | Compressor | | /Compressor| |Decompressor| +---------------+ +------------+ +------------+ | | | |/----------------------\|/----------------------------\| |\------IP/UDP/RTP------/|\-------------IP/UDP/RTP-----/| | | | |----------+ +----------|/----------------------------\| |IP/UDP/RTP| |IP/UDP/RTP|\---IP/UDP/Tunnel-protoccol--/| |----------+ +----------| | | MSN/CRC |->| MSN/CRC | | |----------+ +----------| | | Payload | | Payload |-------------+ +-------------| |----------+ +----------|IP/UDP/Tunnel| |IP/UDP/Tunnel| | |-protoccol | | -protoccal | | |-------------+ +-------------| | | IP/UDP/RTP |->| IP/UDP/RTP | | |-------------+ +-------------| | | MSN/CRC | | MSN/CRC | | |-------------+ +-------------| | | Payload | | Payload | | |-------------+ +-------------| | | | | | | | | | ----- ----- ----- picture 5 process of nested compression As shown above, context of IP / UDP / RTP header compression context is established between compressor and decompressor; context of IP / UDP / TUNNEL-PROTOCAL header compression profile is established between intermediate and decompressor. ROHC header format of IP / UDP / RTP compressed protocol package sent by UE is shown in Table 1[RFC5225]. Wei & zhu Expires December 24, 2010 [Page 8] Internet-Draft Nested compression June 2010 0 1 2 3 4 5 6 7 --- --- --- --- --- --- --- --- : Add-CID octet : +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 1 0 x | +---+---+---+---+---+---+---+---+ : : / 0-2 octets of CID / : : +---+---+---+---+---+---+---+---+ | Profile | +---+---+---+---+---+---+---+---+ | CRC | +---+---+---+---+---+---+---+---+ | MSN or LSB | +---+---+---+---+---+---+---+---+ | | / Profile specific information / | | - - - - - - - - - - - - - - - - table 1 ROHC header format of IP / UDP / RTP compressed protocol package sent by UE CID:CID index the context table. The CID space can be either small, which means that CIDs can take the values 0 through 15, or large, which means that CIDs take values between 0 and 2^14 - 1 = 16383. Whether the CID space is large or small MUST be established, possibly by negotiation, before any compressed packet may be sent over the ROHC channel. Profile: A ROHC profile defines the elements that build up the compression protocol. CRC: The CRC verification refers to the verification of the result of a decompression attempt using the 3-bit CRC or 7-bit CRC included in the header of a compressed packet format. MSN: Compression of header fields is based on the establishment of a function to a sequence number, called the master sequence number(MSN). LSB: Least Significant Bit. A profile is identified by a 16-bit value, where the 8 LSB bits indicate the actual profile, and the 8 MSB bits indicate the variant of that profile. Wei & zhu Expires December 24, 2010 [Page 9] Internet-Draft Nested compression June 2010 After adding the outer layer of protocol packet (IP / UDP / TUNNEL- PROTOCOL) at the intermediate node, we can make nested compression .A part of the functional information (eg, Sequence number, CRC check) of the inner ROHC header field(IP/UDP/RTP ) can be used by the outer ROHC header field(IP/UDP/TUNNEL-PROTOCOL). The inner ROHC header field(IP/UDP/RTP ) and the outer ROHC header field(IP/UDP/TUNNEL-PROTOCOL) can be seen respectively in table 2 and table 3. 0 1 2 3 4 5 6 7 --- --- --- --- --- --- --- --- : Add-CID octet : +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 1 0 x | +---+---+---+---+---+---+---+---+ : : / 0-2 octets of CID / : : +---+---+---+---+---+---+---+---+ | Profile | +---+---+---+---+---+---+---+---+ | | +---+---+---+---+---+---+---+---+ | | +---+---+---+---+---+---+---+---+ | | / Profile specific information / | | - - - - - - - - - - - - - - - - table 2 inner ROHC header field(IP/UDP/RTP ) Wei & zhu Expires December 24, 2010 [Page 10] Internet-Draft Nested compression June 2010 0 1 2 3 4 5 6 7 --- --- --- --- --- --- --- --- : Add-CID octet : +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 1 0 x | +---+---+---+---+---+---+---+---+ : : / 0-2 octets of CID / : : +---+---+---+---+---+---+---+---+ | Profile | +---+---+---+---+---+---+---+---+ | CRC | +---+---+---+---+---+---+---+---+ | MSN or LSB | +---+---+---+---+---+---+---+---+ | | / Profile specific information / | | - - - - - - - - - - - - - - - - table 3 outer ROHC header field(IP/UDP/TUNNEL-PROTOCOL) In the outer nested compression IP / UDP / TUNNEL-PROTOCOL header, CRC field is necessary to integrate the CRC field of compression IP / UDP / RTP protocol header and re-calculate; MSN field can be directly copied from the MSN field of the inner nested compression IP / UDP / RTP header. At the same time, in order to reduce the repeat field inner and outer of the nested compression, we can remove the CRC and MSN field of the inner ROHC packet to improve the compression efficiency, saving transmission radio resources. 6. CRC Considerations 6.1. CRC in compressed headers The CRC in compressed headers is calculated over all octets of the entire original header, before compression, in the following manner[RFC3095]. The octets of the header are classified as either CRC-STATIC or CRC- DYNAMIC, and the CRC is calculated over: Wei & zhu Expires December 24, 2010 [Page 11] Internet-Draft Nested compression June 2010 1. the concatenated CRC-STATIC octets of the original header, placed in the same order as they appear in the original header, followed by 2. the concatenated CRC-DYNAMIC octets of the original header, placed in the same order as they appear in the original header. The intention is that the state of the CRC computation after 1) will be saved. As long as the CRC-STATIC octets do not change, the CRC calculation will then only need to process the CRC-DYNAMIC octets. In a typical RTP/UDP/IPv4 header, 25 octets are CRC-STATIC and 15 are CRC-DYNAMIC. In a typical RTP/UDP/IPv6 header, 49 octets are CRC- STATIC and 11 are CRC-DYNAMIC. This technique will thus reduce the computational complexity of the CRC calculation by roughly 60% for RTP/UDP/IPv4 and by roughly 80% for RTP/UDP/IPv6. Note: Whenever the CRC-STATIC fields change, the new saved CRC state after 1) is compared with the old state. If the states are identical, the CRC cannot catch the error consisting in the decompressor not having updated the static context. In U/O-mode the compressor SHOULD then for a while use packet types with another CRC length, for which there is a difference in CRC state, to ensure error detection. The initial content of the CRC register is preset to all 1's. The polynomial to be used for the 3 bit CRC is: C(x) = 1 + x + x^3 The polynomial to be used for the 7 bit CRC is: C(x) = 1 + x + x^2 + x^3 + x^6 + x^7 The CRC in compressed headers is calculated over the entire original header, before compression. 6.2. Discussion of CRC problem in nested compression Here, there are two cases of nested compression in the scenario: one is that the data packet is transmitted from the sender to the intermediate node, but the intermediate node dose not decompress the packet. The intermediate node makes nested compression with the whole nested packet header after add the outer packet header, and then forwards it directly to the receiver. Another is that the data packet is transmitted from the sender to the intermediate node,and the intermediate node decompress the packets received. The intermediate node compresses the inner and outer of nested packet Wei & zhu Expires December 24, 2010 [Page 12] Internet-Draft Nested compression June 2010 respectively, then forwards it to the receiver . The first case: as the intermediate node does not decompresses the packet sent by the sender, i.e. it carries out CRC only at the receiver but not at the intermediate node, if a CRC check fails, the receiver can not determines where error has occurred , at the transmission link between sender and intermediate node or between intermediate node and receiver. In this case, the receiver has to send NACK to the sender and request the retransmission of packet. The second case: the intermediate node carries out CRC when decompresses the packet sent by the sender. if a CRC check fails, it can determines that error has occurred at the transmission link between sender and intermediate node, then intermediate node returns the NACK to the sender for packet retransmission. If a CRC check does not fails at intermediate node , but a CRC check fails at the receiver, it can be judged that error has occurred at the transmission link between intermediate node and receiver, then receiver return the NACK to intermediate node to request packet retransmission. 7. Security Considerations TBD 8. IANA Considerations There have been no IANA considerations so far in this document. 9. Acknowledgments TBD 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. Wei & zhu Expires December 24, 2010 [Page 13] Internet-Draft Nested compression June 2010 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", RFC 5225, April 2008. Authors' Addresses Anni Wei Huawei Technologies Huawei Building, Xinxi Road No.3 Haidian District, Beijing 100085 P. R. China Phone: +86-10-82836297 Email: weianni@huawei.com Lei Zhu Huawei Technologies Huawei Building, Xinxi Road No.3 Haidian District, Beijing 100085 P. R. China Phone: +86-10-82836301 Email: Lei.zhu@huawei.com Wei & zhu Expires December 24, 2010 [Page 14]