tsvwg L. Zhu Internet-Draft Huawei Intended status: Standards Track June 22, 2010 Expires: December 24, 2010 Requirements and ROHC compression profile for SCTP draft-lei-tsvwg-sctp-compr-requirements-profile-00 Abstract This document is to specify the requirements to compress headers of IP/SCTP package and how ROHC mechanism compresses SCTP. Streaming Control Transport Protocol is new generation IP transport protocol which has been published in RFC2960 and updated by RFC4960. SCTP can maintain association among multiple peers, thus supports multiple homing and multiple streaming, while inherits most functions of TCP. SCTP as transport protocol has been used to carry signaling or possible user plane data in turbulence network which needs to save spectrum resource by compressing IP headers. 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 Zhu Expires December 24, 2010 [Page 1] Internet-Draft Compression Profile for SCTP June 2010 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of 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. Zhu Expires December 24, 2010 [Page 2] Internet-Draft Compression Profile for SCTP June 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Requirement and scenarios . . . . . . . . . . . . . . . . . . 4 3.1. Scenarios to compress IP/SCTP package headers . . . . . . 4 3.2. General requirements to ROHC protocol . . . . . . . . . . 6 3.3. Headers of IP package proposed to compress . . . . . . . . 6 3.4. SCTP specific requirements . . . . . . . . . . . . . . . . 7 3.5. Transport Protocol Requirements . . . . . . . . . . . . . 8 4. Compression and Design Rationale . . . . . . . . . . . . . . . 14 4.1. Supports to ROHCv1 and ROHCv2 . . . . . . . . . . . . . . 14 4.2. Operation Assumptions . . . . . . . . . . . . . . . . . . 14 4.3. Concept of SCTP packet compression . . . . . . . . . . . . 15 4.4. Compressor and Decompressor Interactions . . . . . . . . . 15 4.4.1. Behavior of Compressor . . . . . . . . . . . . . . . . 15 4.4.2. Behavior of Compressor . . . . . . . . . . . . . . . . 16 5. Packet Types . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Initialization and Refresh (IR) Packets . . . . . . . . . 16 5.2. IR-DYN Packets . . . . . . . . . . . . . . . . . . . . . . 18 5.3. Compressed (CO) Packets . . . . . . . . . . . . . . . . . 18 6. Header Formats . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Feedback Formats and Options . . . . . . . . . . . . . . . 18 6.1.1. Feedback Formats . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. Normative References . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Zhu Expires December 24, 2010 [Page 3] Internet-Draft Compression Profile for SCTP June 2010 1. Introduction SCTP RFC4960 [1] is a reliable transport protocol operating on top of a connectionless packet network such as IP. SCTP has been used to carry signaling in LTE (Long Term Evolution) architecture which named as 3.9 generation wireless network. SCTP is also potentially used to transfer user plane data in different type of access network. Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. The ROHC framework, along with a set of compression profiles, was initially defined in RFC3095 [4]. In addition, ROHCv2 which predigests state transformation protocol was published in RFC5225 [5]. As SCTP has been as the role of transport user data in various types of access network including some high error rate or turbulence environments, SCTP is to be compressed by ROHC protocol together IP headers. The intention of this document is to finalize the header compression profile of IP/SCTP package and finally meets the requirements to reduce overhead due to duplicated IP/SCTP headers. 2. Requirements Language 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 [2]. 3. Requirement and scenarios The following requirements have, more or less arbitrarily, been divided into five groups. The first group deals with requirements concerning the impact of a header compression scheme on the rest of the Internet infrastructure. 3.1. Scenarios to compress IP/SCTP package headers The original motivation is that the SCTP as transport protocol could be revealed in high error rate links. For instance, the venders of wireless network can settle intermediate base stations to supply radio access resource in particular area (hot spot or very few using area). Zhu Expires December 24, 2010 [Page 4] Internet-Draft Compression Profile for SCTP June 2010 3GPP relay architecture: \ | / \ | / |__ -- -- -- \|/ -- -- -- -- - \|/ _____ | | __|__ __|__ | | |__| | | | | |__ | | | | | |__|__| |_____| |_____| | |__________________| MS BS#1 BS#2 CN entity The wireless link is established between the first base station and the second base station in above picture. This wireless link between base stations takes responsibilities of user data and signaling transport. Therefore, the transport protocol like SCTP will be desirable to transport user data and singalling at the same time within a SCTP association. The protocol stack in such air interface could be found in following picture. Corresponding protocol stack: +-------------+ | +-------------+ | Application |------|-----| Application | +-------------+ | +-------------+ | SCTP |------|-----| SCTP | +-------------+ | +-------------+ | IP |------|-----| IP | +-------------+ | +-------------+ | L2 |------|-----| L2 | +-------------+ | +-------------+ | L1 |------|-----| L1 | +-------------+ | +-------------+ BS#1 Radio interface BS#2 SCTP packet can be used to carry signaling in the control plane of air interface in wireless network. The scenarios which the wireless network architecture reveals IP/SCTP packets in air interface can explain the needs to compress headers of IP/SCTP packets. Zhu Expires December 24, 2010 [Page 5] Internet-Draft Compression Profile for SCTP June 2010 In general, the IP/SCTP packets take place in air interface with at least IP/SCTP headers which are desirable to be compressed by ROHC mechanisms. Since the SCTP association among endpoints is likely kept for a long time, the amount of reduced traffic in radio network could be remarkable from spectrum point of view. 3.2. General requirements to ROHC protocol 1. Transparency: When a header is compressed and then decompressed, the resulting header must be semantically identical to the original header. If this cannot be achieved, the packet containing the erroneous header must be discarded. Justification: The header compression process must not produce headers that might cause problems for any current or future part of the Internet infrastructure. Note: The ROHC WG has not found a case where "semantically identical" is not the same as "bitwise identical". 2. Ubiquity: Must not require modifications to existing IP (v4 or v6) or SCTP implementations. Justification: Ease of deployment. Note: The ROHC WG may recommend changes that would increase the compression efficiency for the SCTP streams emitted by implementations. However, ROHC cannot rely on such recommendations being followed. 3. Compression efficiency The compression efficiency is determined by how much the average header size is reduced by applying the compression protocol. 4. Robustness A robust protocol tolerates packet losses, residual bit errors, and out-of-order delivery on the link over which header compression takes place, without losing additional packets or introducing additional errors in decompressed headers. 3.3. Headers of IP package proposed to compress (1) IPv4 and IPv6: Must support both IPv4 and IPv6. This means that all possible changes in the IP header fields must be handled by the compression scheme and commonly changing fields should be compressed efficiently. Zhu Expires December 24, 2010 [Page 6] Internet-Draft Compression Profile for SCTP June 2010 Justification: IPv4 and IPv6 will both be around during the foreseeable future. (2) Mobile IP: The kinds of headers used by Mobile IP{v4,v6} must be supported and should be compressed efficiently. For IPv4 these include headers of tunneled packets. For IPv6 these include headers containing the Routing Header, the Binding Update Destination Option, and the Home Address option. Justification: It is very likely that Mobile IP will be used by cellular devices. (3) IPSEC: The scheme should be able to compress headers containing IPSEC sub-headers. Justification: IPSEC is expected to be used to provide necessary end- to-end security. Note: It is of course not possible to compress the encrypted part of an ESP header, nor the cryptographic data in an AH header. 3.4. SCTP specific requirements (1) Performance/Spectral Efficiency: Must provide low relative overhead under expected operating conditions. Justification: Spectrum efficiency is the primary goal here. (2) Error propagation: For SCTP traffic, link layer retransmissions should be applied to make use of the bandwidth in the most efficient way. Lost or damaged headers should thus not occur and therefore it is not a primary goal to have mechanisms for error propagation avoidance in case of such events. Justification: To provide robustness against loss or damage introduced by the link, efficiency must be sacrificed. Since loss or damage is not expected for SCTP traffic, efficiency should instead be prioritized. This does not mean that some robustness should not be provided, if efficiency can still be optimized. Note: In general, error propagation due to header compression should be kept at an absolute minimum. Error propagation is defined as the loss or damage of headers subsequent to headers lost or damaged by the link, even if those subsequent headers are not lost or damaged. Note: There are at least two kinds of error propagation; loss propagation, where a lost header causes subsequent headers to be lost or damaged, and damage propagation, where a damaged header causes Zhu Expires December 24, 2010 [Page 7] Internet-Draft Compression Profile for SCTP June 2010 subsequent headers to be lost or damaged. (3) Short lived SCTP transfers: The scheme should provide mechanisms for efficient compression of short-lived SCTP transfers, minimizing the size of context initiation headers. Justification: Many SCTP transfers are short-lived. This means that the gain of header compression could be low since normally header compression sends full headers initially and small compressed headers first after the initiation phase. Note: This requirement implies that mechanisms for "context sharing" or "context re-use" should be considered. (4a) Moderate Packet Reordering: The scheme should efficiently handle moderate reordering (2-3 packets) in the packet stream reaching the compressor. Justification: This kind of reordering is common. (4b) Packet Reordering: The scheme should be able to compress when there are reordered packets in the SCTP stream reaching the compressor. Justification: Reordering happens regularly in the Internet. However, since the Internet is engineered to run SCTP reasonably well, excessive reordering will not be common and need not be handled with optimum efficiency. (5) Processing delay: The scheme must not contribute significantly to system delay budget. 3.5. Transport Protocol Requirements SCTP is connection-oriented in nature, but the SCTP association is a broader concept than the TCP connection. SCTP provides the means for each SCTP endpoint to provide the other endpoint (during association startup) with a list of transport addresses (i.e., multiple IP addresses in combination with an SCTP port) through which that endpoint can be reached and from which it will originate SCTP packets. The association spans transfers over all of the possible source/destination combinations that may be generated from each endpoint's lists. An SCTP packet is composed of a common header and chunks which contain either control information or user data. A chunk is a unit of information within an SCTP packet, consisting of a chunk header and chunk-specific content. Zhu Expires December 24, 2010 [Page 8] Internet-Draft Compression Profile for SCTP June 2010 The SCTP packet format is shown below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Common Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk #n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SCTP Header Format The value of common headers would be mostly unchanged during signaling or data transportation. Therefore, the common headers are expected to be compressed if the SCTP association last for long time, especially in case of high error rate link. Even though the applications over SCTP like signaling is not sensitive to duplicated Chunk headers, the common headers of SCTP packets are still worth to compress as the same SCTP association carry multiple applications transportation. The common header of a SCTP package would be formed as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port Number | Destination Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Verification Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SCTP Common Header Format Source Port Number: This is the SCTP sender's port number. It can be used by the receiver in combination with the source IP address, the SCTP Zhu Expires December 24, 2010 [Page 9] Internet-Draft Compression Profile for SCTP June 2010 destination port, and possibly the destination IP address to identify the association to which this packet belongs. Destination Port Number: This is the SCTP port number to which this packet is destined. The receiving host will use this port number to de-multiplex the SCTP packet to the correct receiving endpoint/application. Verification Tag: The receiver of this packet uses the Verification Tag to validate the sender of this SCTP packet. On transmit, the value of this Verification Tag MUST be set to the value of the Initiate Tag received from the peer endpoint during the association initialization, with some exceptions. Checksum: This field contains the checksum of this SCTP packet. SCTP uses the CRC32c algorithm as described in Appendix B for calculating the checksum. Previous ROHC mechanisms do not rely on the function of Checksum of IP and transport protocol for robustness though Checksum is appreciate error detection approach. SCTP also defines a number of types of chunks in a SCTP package. A number of Chunk types are used to initiate and maintains SCTP association. Other registered SCTP Chunk types are used for particular application, and can be found at the website http://www.iana.org. One Chunk type registered for 3GPP RAN2 and RAN3 S1-AP (S1 interface application (S1-AP) is the name of the protocol carry mobile network signaling.) is included in the compression profile, therefore the headers of S1-AP Chunk type are in the scope of this document. The types and the value of Chunks are listed as following: Zhu Expires December 24, 2010 [Page 10] Internet-Draft Compression Profile for SCTP June 2010 The values of Chunk Types are defined as follows: ID Value Chunk Type ----- ---------- 0 - Payload Data (DATA) 1 - Initiation (INIT) 2 - Initiation Acknowledgement (INIT ACK) 3 - Selective Acknowledgement (SACK) 4 - Heartbeat Request (HEARTBEAT) 5 - Heartbeat Acknowledgement (HEARTBEAT ACK) 6 - Abort (ABORT) 7 - Shutdown (SHUTDOWN) 8 - Shutdown Acknowledgement (SHUTDOWN ACK) 9 - Operation Error (ERROR) 10 - State Cookie (COOKIE ECHO) 11 - Cookie Acknowledgement (COOKIE ACK) 12 - Reserved for Explicit Congestion Notification Echo (ECNE) 13 - Reserved for Congestion Window Reduced (CWR) 14 - Shutdown Complete (SHUTDOWN COMPLETE) 15 to 62 - available 63 - reserved for IETF-defined Chunk Extensions 64 to 126 - available 127 - reserved for IETF-defined Chunk Extensions 128 to 190 - available 191 - reserved for IETF-defined Chunk Extensions 192 to 254 - available 255 - reserved for IETF-defined Chunk Extensions The header part of SCTP chunk of user data type are formed as following format: The following format MUST be used for the DATA chunk: Zhu Expires December 24, 2010 [Page 11] Internet-Draft Compression Profile for SCTP June 2010 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0 | Reserved|U|B|E| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier S | Stream Sequence Number n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Protocol Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / User Data (seq n of Stream S) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Data Chunk Format +---------------------+-------------+----------------+ | Field | Size (bits) | Class | +---------------------+-------------+----------------+ | Source Port | 16 | STATIC-DEF | | Destination Port | 16 | STATIC-DEF | | Verification Tag | 32 | STATIC | | Checksum | 32 | CHANGING | +---------------------+-------------+----------------+ Figure x: SCTP header fields +---------------------+-------------+----------------+ | Field | Size (bits) | Class | +---------------------+-------------+----------------+ | TYPE | 8 | STATIC | | Reserved | 5 | STATIC | | U|B|E| | 3 | STATIC-DEF | | TSN | 32 | CHANGING | | Stream Identifier S | 16 | STATIC-DEF | | Stream Sequence | 16 | STATIC-DEF | | Number | | | | Payload Protocol | 16 | STATIC-DEF | | Identifier | | | +---------------------+-------------+----------------+ Figure x: Data chunk header fields |U|B|E| Zhu Expires December 24, 2010 [Page 12] Internet-Draft Compression Profile for SCTP June 2010 The U/B/E is defined for indicating reordering, beginning fragment and ending fragment in the SCTP packet. Length This field indicates the length of the DATA chunk in bytes from the beginning of the type field to the end of the User Data field excluding any padding. A DATA chunk with one byte of user data will have Length set to 17 (indicating 17 bytes). A DATA chunk with a User Data field of length L will have the Length field set to (16 + L) (indicating 16+L bytes) where L MUST be greater than 0. TSN: This value represents the TSN for this DATA chunk. The valid range of TSN is from 0 to 4294967295 (2**32 - 1). TSN wraps back to 0 after reaching 4294967295. Stream Identifier S: Identifies the stream to which the following user data belongs. Stream Sequence Number n: This value represents the Stream Sequence Number of the following user data within the stream S. Valid range is 0 to 65535. When a user message is fragmented by SCTP for transport, the same Stream Sequence Number MUST be carried in each of the fragments of the message. Payload Protocol Identifier: This value represents an application (or upper layer) specified protocol identifier. This value is passed to SCTP by its upper layer and sent to its peer. This identifier is not used by SCTP but can be used by certain network entities, as well as by the peer application, to identify the type of information being carried in this DATA chunk. This field must be sent even in fragmented DATA chunks (to make sure it is available for agents in the middle of the network). Note that this field is NOT touched by an SCTP implementation; therefore, its byte order is NOT necessarily big endian. The upper layer is responsible for any byte order conversions to this field. The value 0 indicates that no application identifier is specified by the upper layer for this payload data. Zhu Expires December 24, 2010 [Page 13] Internet-Draft Compression Profile for SCTP June 2010 4. Compression and Design Rationale 4.1. Supports to ROHCv1 and ROHCv2 ROHCv1 was defined in RFC3095 [4]. The ROHCv2 was defined in RFC5225 [5]. The header compression profile for SCTP would be compliant with ROHCv1 and ROHCv2 mechanisms. The vales of compression profile would be identified as profile for ROHCv1 and profile for ROHCv2. 4.2. Operation Assumptions Cellular links, which are a primary target for ROHC, have a number of characteristics that are described briefly here. SCTP is a type of transport protocol to establish a peer to peer association between two endpoints which are able to transfer multiple sorts of applications. The applications between SCTP endpoint in an association include signaling, user data and other association maintenance messages. The pre-defined assumptions are to clarify some concepts of compressing SCTP packets headers. ROHC profile: A ROHC profile is a compression protocol, which specifies how to compress specific header combinations. Each compression profile is associated with a unique ROHC profile identifier. As this profile is used in ROHCv1 and ROHCv2 frameworks, this document would specify two values of compression profile. Each value of profile is associated with one version of ROHC framework. When setting up a ROHC channel, the set of profiles supported by both endpoints of the channel is negotiated, and when initializing new contexts, a profile identifier from this negotiated set is used to associate each compression context with one specific profile. In this document, to address the requirements of compressing SCTP packet header, ROHC profile for SCTP packet headers is defined to recognize and adopt the situation which a SCTP association can start or shutdown a type of chunk except other running chunks. Link: A physical transmission path that constitutes a single IP hop. Similar concept is align with Channel in RFC3095. Each Link has different characteristics in terms of error rate, bandwidth, etc. Flow: A transportation between peers of a SCTP association, which is carried by one chunk of SCTP packet. SCTP association can transfer Zhu Expires December 24, 2010 [Page 14] Internet-Draft Compression Profile for SCTP June 2010 more than one flow at the same time due to SCTP multiple homing ability. Negotiation: The link layer already provides the way to negotiate header compression parameters, e.g. network configuration parameters of 3GPP RAN2 procedure. The ROHC layer SHOULD also assure the ROHC context the particular states and parameters known by compressor and decompressor, e.g. the value of profile, the specific parameters of each profile of an IR or CO packet. 4.3. Concept of SCTP packet compression Compression scheme for SCTP packet MUST support compress common header of the SCTP packet, while transport other Chunk headers as uncompressed state. The compression scheme for SCTP packet SHOULD support compress Chunk header of part of Chunks in the SCTP packet. The compression scheme for SCTP packet SHOULD be capable to inform the identifier of Chunks which headers are to compress, and which MUST be known by decompressor. According to the definition of SCTP RFC5225 [5], the Chunks of the SCTP packet can be identified by Chunk identifier and Chunk type. Additionally, as the mandatory headers to compress, the common headers of the SCTP would be not normally informed to the Decompressor. Therefore, the compressor can take into account starting compression of SCTP packet while a Chunk of a particular Chunk type is established, in addition to compressed common headers of SCTP packet. In principle, the compressor can start and shutdown the compression to the flows carried by Chunks. To fulfill this point, the indication to start or shutdown the compression to the Chunks can be obtained in IR packet and IR-CR packets as specific information of SCTP compression profile. 4.4. Compressor and Decompressor Interactions 4.4.1. Behavior of Compressor The operation between compressor and decompressor can illustrate the characters of compressing interactions. The operation of the compressor is to initiate ROHC context by sending the information which is essential to decompressor the packet. The assumption to decompress the packet sent by compressor is based on the understanding of compression profile with a value which is sent in an Initiate and Refresh packet (IR). The information how to decompress the packet is obtained in initiate and updating behavior, in Zhu Expires December 24, 2010 [Page 15] Internet-Draft Compression Profile for SCTP June 2010 addition, the decompressor can optionally response those information from feedback messages. If the compressor believes the SCTP to sent will be compressed utilizing the particular compression scheme, the compressor MUST initiate compression context by sending IR packet with particular profile number. 4.4.2. Behavior of Compressor Remember, it's important to acknowledge people who have contributed to the work. Attentions to SIP signaling compression related to this draft are expected. 5. Packet Types 5.1. Initialization and Refresh (IR) Packets The IR header format uses the structure of the ROHC IR header as defined in Section 5.2.2.1 of RFC5795 [3]. Header type: IR This header format communicates the static part and the dynamic part of the context. 0 1 2 3 4 5 6 7 --- --- --- --- --- --- --- --- : Add-CID octet : if for small CIDs and (CID != 0) +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 1 0 1 | IR type octet +---+---+---+---+---+---+---+---+ : : / 0-2 octets of CID / 1-2 octets if for large CIDs : : +---+---+---+---+---+---+---+---+ | Profile | 1 octet +---+---+---+---+---+---+---+---+ | CRC | 1 octet +---+---+---+---+---+---+---+---+ : : / Profile specific Information / 2 octet : : +---+---+---+---+---+---+---+---+ Zhu Expires December 24, 2010 [Page 16] Internet-Draft Compression Profile for SCTP June 2010 CRC: 8-bit CRC over the entire IR-header, including any CID fields and up until the end of the dynamic chain, using the polynomial defined in RFC5795 [3]. For purposes of computing the CRC, the CRC field is zero. Profile specific Information: Compression profile for SCTP specifies owned specific information. The function of profile information can setup or close header compression to particular Flow of a Chunk. Thus, the compressor and decompressor using this compression profile for SCTP could compress common headers and headers of part of Chunks in a SCTP packet. For example, the common headers and headers of user date Chunk could be compressed by compressor except other headers of Chunks. In particular scenario, it is possible for compressor to compress only common headers of SCTP packet in case the SCTP association last very long time and just serves for signaling transportations. The format of compression profile information: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | Chunk ID | 1 Octet Chunk Identifiers +---+---+---+---+---+---+---+---+ | Chunk Type | CF| Chunk type and chunk flag +---+---+---+---+---+---+---+---+ Chunk ID: Chunk Identifier (Chunk ID) indicate the Chunk of the SCTP packet which the Initiation and Refresh (IR) packet is to handle. Chunk Identifier is a 8 octets value which is corresponding Chunk of the SCTP packets to be compressed. Chunk Type: Chunk Type is associated with Chunk ID. Chunk Type in IR packet is a 7 octets value which can cover existing Chunk Types of SCTP packet and other 111 available value of Chunk Types for further considerations. CF: Chunk Flag (CF) indicates the start or end of compression operation to headers of particular Chunk which is identified by Chunk ID and Chunk Type. The CF with value '1' indicates the start of compression Zhu Expires December 24, 2010 [Page 17] Internet-Draft Compression Profile for SCTP June 2010 operation. The CF with value '0' indicates the end of compression operation. 5.2. IR-DYN Packets ROHCv2 does not define IR-DYN packet by comparison with corresponding definition of IR-DYN packets. If the compression context is established based on protocol of RPHCv1, the format of IR-DYN is very similar with format of IR packet. Please previous subsection. 5.3. Compressed (CO) Packets The ROHCv2 co_repair header has the following format: 0 1 2 3 4 5 6 7 --- --- --- --- --- --- --- --- : Add-CID octet : if for small CIDs and CID 1-15 +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 0 1 1 | discriminator +---+---+---+---+---+---+---+---+ : : / 0, 1, or 2 octets of CID / 1-2 octets if large CIDs : : +---+---+---+---+---+---+---+---+ |r1 | CRC-7 | +---+---+---+---+---+---+---+---+ | r2 | CRC-3 | +---+---+---+---+---+---+---+---+ | | / Dynamic chain / variable length | | - - - - - - - - - - - - - - - - The parameters of CO packet were illustrated in section 6.8.2.2 of RFC5225 [5]. 6. Header Formats 6.1. Feedback Formats and Options 6.1.1. Feedback Formats ROHCv2 extents use of feedback packet for Compressor and Decompressor. The Feedback packets response the information of Decompressor for one ROHC Context as a whole. Zhu Expires December 24, 2010 [Page 18] Internet-Draft Compression Profile for SCTP June 2010 If the Compressor can distinguish compression information of particular Chunk headers from Feedback information is the question for TBD. 7. Acknowledgements The compression profile for SCTP packet can be used in environments with or without feedback capabilities from decompressor to compressor. The reception of either positive acknowledgment (ACKs) or negative acknowledgment (NACKs) establishes the feedback channel from the decompressor for the context for which the feedback was received. The compression profile has not adopted the feedback concept to each flow binding particular Chunk. The start of feedback highly relies on full duplex Channel of links. The feedback (either ACK or NACK) SHOULD be distinguished by resolving Context identifiers, MSN or LSB, and other possible identifier. 8. IANA Considerations This memo includes no request to IANA. 9. Security Considerations TBD. 10. Normative References [1] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, March 2010. [4] 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. Zhu Expires December 24, 2010 [Page 19] Internet-Draft Compression Profile for SCTP June 2010 [5] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP- Lite", RFC 5225, April 2008. Author's Address Lei Zhu Huawei Technologies Huawei Bld., No.3 Xinxi Rd., Haidian District Beijing CN Phone: +86-10-82836301/+86-13910157020 Email: lei.zhu@huawei.com. Zhu Expires December 24, 2010 [Page 20]