Network Working Group M. West Internet-Draft A. Surtees Expires: August 23, 2002 Siemens/Roke Manor February 22, 2002 SCTP Profile for EPIC draft-west-sctp-epic-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. This Internet-Draft will expire on August 23, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This draft describes a profile for compressing SCTP/IP using the Efficient Protocol Independent Compression (EPIC) [2] scheme. The RObust Header Compression [1] scheme is designed to compress packet headers over error prone channels. It is built around an extensible core framework that can be tailored to compress new protocol stacks by adding additional ROHC profiles. This profile describes a new profile for ROHC which will allow SCTP/ IP headers to be compressed. West & Surtees Expires August 23, 2002 [Page 1] Internet-Draft SCTP Profile for EPIC February 2002 Note This is a preliminary profile. It is documented in this draft for two main reasons. 1. To encourage discussion regarding the compression of SCTP 2. To explore the range of protocols that EPIC can be used to compress Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . 3 3. Framework . . . . . . . . . . . . . . . . . . . . . . . 4 4. Basic SCTP/IPv4 Header . . . . . . . . . . . . . . . . . 4 5. SCTP/IPv4 Profile for EPIC . . . . . . . . . . . . . . . 6 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1.1 High-level Structure . . . . . . . . . . . . . . . . . . 7 5.1.1.1 IPv4 header compression . . . . . . . . . . . . . . . . 7 5.1.1.2 SCTP header . . . . . . . . . . . . . . . . . . . . . . 8 5.1.1.2.1 Common Header . . . . . . . . . . . . . . . . . . . . . 8 5.1.1.2.2 Chunks . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1.2 Limitations and restrictions . . . . . . . . . . . . . . 9 5.2 Additional Encoding Methods . . . . . . . . . . . . . . 10 5.2.1 PADDING . . . . . . . . . . . . . . . . . . . . . . . . 11 5.3 The Profile . . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . 26 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 26 References . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . 27 A. Pseudo-code for PADDING method . . . . . . . . . . . . . 28 Full Copyright Statement . . . . . . . . . . . . . . . . 30 West & Surtees Expires August 23, 2002 [Page 2] Internet-Draft SCTP Profile for EPIC February 2002 1. Introduction This document describes a profile for compressing SCTP/IP. The Stream Control Transmission Protocol [6] may have application in the same areas that Robust Header Compression was designed to target. Requirements for the compression of SCTP are discussed in [3]. This profile assumes the use of the ROHC [1] framework but using EPIC [2] to derive the new set of header formats. The aim of this profile is to produce header formats which can be used along with the framework of ROHC to compress SCTP. The compression of the protocol is defined in the EPIC input language. The EPIC framework takes a profile as its input. A profile describes the fields of a particular protocol header using a form of BNF. This BNF also describes how to compress each field using one or more of the toolbox methods defined in the EPIC framework. Consequently to describe how to compress a new protocol, all that is needed is a profile. This draft gives the profile for SCTP. For more details about the EPIC framework and the process of generating packets, refer to [2]. 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 RFC-2119. Profile A ROHC [1] profile is a description of how to compress a certain protocol stack over a certain type of link. Each profile includes one or more sets of compressed header formats and a state machine to control the compressor and the decompressor. Chunk A unit of information within an SCTP packet, consisting of a chunk header and chunk-specific content. SCTP packet The unit of data delivery across the interface between SCTP and the connectionless packet network (e.g., IP). An SCTP packet includes the common SCTP header, possible SCTP control chunks, and user data encapsulated within SCTP DATA chunks. Stream West & Surtees Expires August 23, 2002 [Page 3] Internet-Draft SCTP Profile for EPIC February 2002 A uni-directional logical channel established from one to another associated SCTP endpoint, within which all user messages are delivered in sequence except for those submitted to the unordered delivery service. For more definitions of SCTP terms, see [6]. 3. Framework The overall framework in which to run this profile, that is the context identifier (CID), basic packet identifiers, e.g. IR, IR-DYN, are as defined in ROHC [1]. For the sake of simplicity, the profile is initially described for uni-directional operation. No feedback packets are defined. The state machine at the compressor has to decide whether to send IR, IR-DYN or CO packets as described in the EPIC framework. 4. Basic SCTP/IPv4 Header The base fields of each header are as shown below (note these diagrams are compatible with those in ROHC [1]): West & Surtees Expires August 23, 2002 [Page 4] Internet-Draft SCTP Profile for EPIC February 2002 IPv4 Header +----+----+----+----+----+----+----+----+ | Version = 4 | Header length = 5 | +----+----+----+----+----+----+----+----+ | Type of Service | +----+----+----+----+----+----+----+----+ / Length / 2 octets +----+----+----+----+----+----+----+----+ / Identification / 2 octets +----+----+----+----+----+----+----+----+ | RF | DF | MF | Fragment Offset = 0 | +----+----+----+----+----+----+----+----+ | Time to Live | +----+----+----+----+----+----+----+----+ | Protocol = 17 | +----+----+----+----+----+----+----+----+ | Checksum | +----+----+----+----+----+----+----+----+ / Source Address / 4 octets +----+----+----+----+----+----+----+----+ / Destination Address / 4 octets +----+----+----+----+----+----+----+----+ o Header length = 5 assuming no IP options. o RF (Reserved Flag) and MF (More Fragments flag) assumed to be zero by [1]. SCTP Common Header +----+----+----+----+----+----+----+----+ / Source Port / 2 octets +----+----+----+----+----+----+----+----+ / Destination Port / 2 octets +----+----+----+----+----+----+----+----+ / Verification Tag / 4 octets +----+----+----+----+----+----+----+----+ / Checksum / 4 octets +----+----+----+----+----+----+----+----+ o The compression profile does not care whether or not the checksum is an Adler-32 checksum as described in [6] or a 32-bit CRC since the checksum is carried transparently by the compression scheme. West & Surtees Expires August 23, 2002 [Page 5] Internet-Draft SCTP Profile for EPIC February 2002 SCTP packet structure +----+----+----+----+----+----+----+----+ / IP Header / 20 octets +----+----+----+----+----+----+----+----+ / Common Header / 12 octets +----+----+----+----+----+----+----+----+ / SCTP Chunk / 4+ octets +----+----+----+----+----+----+----+----+ : : : Further Chunks : : : +----+----+----+----+----+----+----+----+ Generic SCTP Chunk +----+----+----+----+----+----+----+----+ | Type | +----+----+----+----+----+----+----+----+ | Chunk Flags | +----+----+----+----+----+----+----+----+ / Length / 2 octets +----+----+----+----+----+----+----+----+ : : : Payload : x octets : : +----+----+----+----+----+----+----+----+ / Padding / 0-3 octets +----+----+----+----+----+----+----+----+ o Length defines the length of the chunk including the type, flags, length and payload fields. o 0 to 3 octets of padding are added to ensure that the total size of the chunk is an integer multiple of 4 octets The input language describes each of these fields so the compressor need have no prior knowledge of what the header looks like. 5. SCTP/IPv4 Profile for EPIC 5.1 Overview This section gives an overview of how the EPIC profile for SCTP compression is structured. That is, it briefly discusses the components of an SCTP packet at a high level and explains how the packet is processed. West & Surtees Expires August 23, 2002 [Page 6] Internet-Draft SCTP Profile for EPIC February 2002 Note: More detailed descriptions of the behaviour of SCTP protocol fields could be added as an appendix. 5.1.1 High-level Structure SCTP is quite different from transport protocols such as UDP and TCP. This is primarily because a packet can contain multiple 'chunks'. Each chunk is associated with a sub-flow and follows a standard 'type/length/value' encoding. This means that the entire packet is processed by the profile, with the contents of certain chunks (particularly data chunks) being transmitted as 'UNCOMPRESSED' data. The process of compression is exactly the same as for any EPIC profile. The profile contains a description of the SCTP packet that is sufficient to allow it to be compressed. The following explanation refers to the profile in Section 5.3. The overall profile is broken down into top-level elements for the IR, IR-DYN and CO (compressed) packet formats. The generation and usage of these different types of packets within header compression is described in the EPIC-lite framework [2] and ROHC [1]. These top-level elements compress (for this simple example profile) the IPv4 header, the SCTP common header and a list of SCTP chunks. 5.1.1.1 IPv4 header compression The IP header is not particularly complex with regard to compression. Many of the fields are static, or rarely change. A detailed description of IP header fields is given in [1]. The major differences for the handling of the IP header in the SCTP case are as follows: o The TOS field is split to include the ECN bits. Although the ECN chunk types are reserved in [6], they are not defined. However, their presence indicates an intent to deal with ECN, so the IP TOS bits are split accordingly. o The IP length field is not dealt with within the IP header, but preserved on the EPIC control-data stack. This is because there is no length indication in the SCTP header, but the use of EPIC 'LIST' compression requires the length of the list (in this case the packet) to be known. o The IP ID field cannot obviously be tied to another field, as in the case with the RTP sequence number in [1]. Therefore, it is West & Surtees Expires August 23, 2002 [Page 7] Internet-Draft SCTP Profile for EPIC February 2002 encoded in-situ. 5.1.1.2 SCTP header The SCTP header can itself be sub-divided into the common header and one or more chunks (of various types) that may be present. These are considered in the following sections. 5.1.1.2.1 Common Header The SCTP common header, as outlined previously, is quite simple. The port numbers are handled as for other transport protocols, such as UDP and TCP. That is, they are expected to remain static within a flow. The verification tag is also expected to remain unchanged, once established. The checksum is carried transparently in every compressed packet. 5.1.1.2.2 Chunks An SCTP packet can contain one or more chunks and these chunks may belong to one or more streams. The core part of the profile for compressing the SCTP chunk headers is a large 'LIST' encoding. This encoding allows for the compression of a list of items which may be optionally present in a header and/or occur in an arbitrary order. This is, therefore, the logical encoding to use as a basis for the chunks. As discussed earlier, chunks have a standard 'type/length/value' layout. For some chunks, for example Shutdown, the value part can be explicitly encoded, since is has well-defined, fixed contents. In many cases, however, the format of the value part is not known. (The most obvious example of this would be the payload of a data chunk). Here the UNCOMPRESSED method is used to simply convey this information to the decompressor without any compression being applied. However, the data needs to be accounted for in the profile in order for the start of the next chunk to be located. The remainder of this section contains notes relating to the encoding of specific chunk types. o Each data chunk contains a header and payload. The header fields (transaction sequence number, stream ID, stream sequence number, PPI) are encoded as a 'sub-header' in their own right. It is up to the compressor to choose how to manage the available data-chunk encodings in the list to achieve best efficiency. For example, each instance of a data-chunk in the list might be associated with West & Surtees Expires August 23, 2002 [Page 8] Internet-Draft SCTP Profile for EPIC February 2002 a different stream. The 'CONTEXT' encoding is also used to allow the compressor to maintain a number of copies of the context for each list entry. This gives the compressor more flexibility in dealing with data chunks. It also adds support for a larger number of streams than could be handled by only using the LIST construct. o The Init chunk contains a fixed set of fields (including the initiate tag, advertised receive window, numbers of streams in and out, and intial transaction sequence number) as well as some opaque data that is treated as 'UNCOMPRESSED'. The fixed header fields are individually encoded. Only one Init chunk is supported per SCTP packet. o The Init ACK chunk is encoded in essentially the same way as the Init chunk. o The SACK chunk is currently a place-holder encoding, which will be replaced with a more efficienct encoding. The current profile identifies the list of SACK blocks and duplicate TSNs and uses 'LIST' encoding to process them in a simple, but structured, way. o The Heartbeat, Heartbeat-ACK, Abort and Cookie-Echo chunks follow the standard chunk layout but, other than the fields mandated by this structure, contain only opaque data that is carried as 'UNCOMPRESSED'. o The Shutdown, Shutdowm-ACK, Cookie-ACK and Shutdown-Complete chunks contain only well-defined fields, so the entire contents of these chunks are encoded. o The SCTP Error chunk contains a list of error causes and this structure is repeated in the profile, which encodes the list of causes. o The ECNE and CWR chunks are reserved in the [6] but not defined. Thus, currently, they are treated as 'generic'. o Since SCTP may introduce new chunk types, a 'generic' chunk coding is included which takes advantage of the 'type/length/value' structure of chunks to provide a simple encoding for any chunk. 5.1.2 Limitations and restrictions This is, as noted at the start, a preliminary SCTP profile. Thus it should not be seen as definitive, although the profile is sufficient to achieve relatively efficient compression of SCTP. This section West & Surtees Expires August 23, 2002 [Page 9] Internet-Draft SCTP Profile for EPIC February 2002 identifies some of the key areas of the profile that need further consideration. o Up to 4 data chunks can be handled. The 'LIST' encoding requires an upper bound on the number of entries. (Each encoding in a 'LIST' can only be used once per packet). This means that an arbitrary limit on the number of data chunks needs to be set. Currently this is four, although any value could be used. Note that if the 'LIST' encoding fails (due to there being too many data chunks, for example), then the packet will have to be sent as uncompressed. Careful selection of the repeat count is one way of mitigating this. Another would be to introduce a more flexible encoding that would only compress the first part of the packet. o No chunk other than a data chunk can appear more than once. This is a compression restriction rather than an SCTP protocol restriction. It is essentially the same as the previous point: there must be a limit on the number of encodings. Note that the use of 'generic' encodings for chunks allow this restriction to be relaxed somewhat. The 'generic' encoding will never be as efficient as an encoding that makes use of the known characteristics of a chunk. However, it prevents the profile from failing when applied to a packet. o The current use of LIST encoding does not permit the complex rules regarding which chunks can appear in a header to be codified. The profile allows (within the constraints of the LIST encoding) for any of the chunks to occur in any order. The effects on efficiency of this need to be assessed and, if necessary, the profile will be updated to remedy any inefficiency. All of the above issues are for further study. 5.2 Additional Encoding Methods Efficient SCTP compression requires the suite of encoding methods listed in [2] to be extended. This only requires that the syntax and semantics of any new encoding methods are adequately defined. West & Surtees Expires August 23, 2002 [Page 10] Internet-Draft SCTP Profile for EPIC February 2002 5.2.1 PADDING ABNF notation: "PADDING(" "," "," "," ")" l = size of the length field, in bits m = overall size must be a multiple of m bits s = size of padding units p = value of padding units The PADDING method allows for redundant padding data to be elided from the compressed packet. It is for use in cases such as SCTP, where blocks of data are 'rounded up' in size to the nearest multiple of a convenient number of bits. In operation, at the compressor the encoding takes the known length of the block of data (from the control stack). It then computes how many blocks of padding should be present and their value. If this matches the data on the uncompressed_data stack then the padding is simply removed. At the decompressor, the same calculation is performed on the length field (from the control stack). The padding is then added directly to the uncompressed_data stack. The PADDING operation leaves the original length of the block of data on the uncompressed_data stack. The PADDING operation does not require any context to be used. It is also assumed to be applied 100% of the time, so there is no probability parameter. For example, an SCTP data chunk is a multiple of 4 bytes (32 bits) long and is padded with octets of '0'. The SCTP chunk length is a field of 16 bits. This translates to the following encoding: PADDING(16,32,8,0) 5.3 The Profile profile_identifier 0xFFFF max_formats 200 max_sets 4 bit_alignment 8 npatterns 224 CO_packet SCTP-IP-CO West & Surtees Expires August 23, 2002 [Page 11] Internet-Draft SCTP Profile for EPIC February 2002 IR_packet SCTP-IP-IR IR_DYN_packet SCTP-IP-DYN ; The profile identifier is a placeholder. ; ; These 3 encodings are the base methods that define the ; encoding of the IPv4/SCTP header ; SCTP-IP-CO = INFERRED-IP-CHECKSUM(IPv4-header-co) sctp-header-co SCTP-IP-IR = INFERRED-IP-CHECKSUM(IPv4-header-ir) sctp-header-ir SCTP-IP-DYN = INFERRED-IP-CHECKSUM(IPv4-header-dyn) sctp-header-dyn ; ; These encodings specify the SCTP common header and the ; chunk list ; sctp-header-ir = sport-ir dport-ir verif-tag-dyn sctp-chksum chunk-list-ir sctp-header-dyn = sport-co dport-co verif-tag-dyn sctp-chksum chunk-list-ir sctp-header-co = sport-co dport-co verif-tag-co sctp-chksum chunk-list-co ; ; The breakdown of field encodings for an IPv4 header ; IPv4-header-co = version header-len West & Surtees Expires August 23, 2002 [Page 12] Internet-Draft SCTP Profile for EPIC February 2002 ecn-co tos-co length ip-id-nbo ip-id-co nbo-flag-co rf-flag df-flag-co mf-flag offset ttl-co protocol ip-chksum src-address-co dst-address-co IPv4-header-dyn = version header-len ecn-dyn tos-dyn length ip-id-nbo ip-id-dyn nbo-flag-dyn rf-flag df-flag-dyn mf-flag offset ttl-dyn protocol ip-chksum src-address-co dst-address-co IPv4-header-ir = version header-len ecn-dyn tos-dyn length ip-id-nbo ip-id-dyn nbo-flag-dyn rf-flag df-flag-dyn mf-flag offset ttl-dyn protocol West & Surtees Expires August 23, 2002 [Page 13] Internet-Draft SCTP Profile for EPIC February 2002 ip-chksum src-address-ir dst-address-ir ; IP version (fixed as 4) ; version = VALUE(4,4,100%) ; IP header length (fixed as 5) ; header-len = VALUE(4,5,100%) ; ECN currently carried transparently. ; ecn-co = IRREGULAR(2,100%) ecn-dyn = IRREGULAR(2,100%) ; IP TOS is a rarely changing field ; tos-co = STATIC(99%) | IRREGULAR(6,1%) tos-dyn = IRREGULAR(6,100%) ; save length for later ; length = STACK-TO-CONTROL(16) ; Check that the IP ID is in network-byte order ; ip-id-nbo = NBO(16) ; IP ID is currently assumed to be essentially monotonically ; increasing. A 'FORMAT' construct could be used to support ; random IP IDs as well. ; ip-id-co = LSB(4,0,90%) | LSB(7,0,9%) | IRREGULAR(16,1%) ip-id-dyn = IRREGULAR(16,100%) ; Indicates the NBO flag for the IP ID ; nbo-flag-co = STATIC(100%) nbo-flag-dyn = IRREGULAR(1,100%) ; Reserved flag assumed to be false (0) West & Surtees Expires August 23, 2002 [Page 14] Internet-Draft SCTP Profile for EPIC February 2002 ; rf-flag = VALUE(1,0,100%) ; DF can only change in IR/IR-DYN packets ; df-flag-co = STATIC(100%) df-flag-dyn = IRREGULAR(1,100%) ; MF is assumed to be false (0) ; mf-flag = VALUE(1,0,100%) ; Offset is assumed to be false (0) ; offset = VALUE(13,0,100%) ; TTL is a rarely changing field ; ttl-co = STATIC(99%) | IRREGULAR(8,1%) ttl-dyn = IRREGULAR(8,100%) ; Fixed value for the SCTP protocol ; protocol = VALUE(8,17,100%) ; IP checksum is handled by INFERRED-IP-CHECKSUM ; ip-chksum = VALUE(16,0,100%) ; Source and destination addresses are set in an IR packet and ; do not change thereafter ; src-address-co = STATIC(100%) src-address-ir = IRREGULAR(32,100%) dst-address-co = STATIC(100%) dst-address-ir = IRREGULAR(32,100%) sport-ir = IRREGULAR(16,100%) dport-ir = IRREGULAR(16,100%) sport-co = STATIC(100%) West & Surtees Expires August 23, 2002 [Page 15] Internet-Draft SCTP Profile for EPIC February 2002 dport-co = STATIC(100%) ; Verification tag is a relatively rarely changing field ; verif-tag-dyn = IRREGULAR(32,100%) verif-tag-co = STATIC(90%) | IRREGULAR(32,10%) ; Checksum is just treated as an unpredictable 32-bit value ; sctp-chksum = IRREGULAR(32,100%) ; The list of allowable chunk types. Each encoding in the LIST ; construct can be used only once per packet ; chunk-list-co = LIST( 16 ; uses IP length 1, 8, -224 ; values for d, m & p 8, ; width of 'type' field OPTIONAL(sctp-data-co), OPTIONAL(sctp-data-co), OPTIONAL(sctp-data-co), OPTIONAL(sctp-data-co), OPTIONAL(sctp-init), OPTIONAL(sctp-init-ack), OPTIONAL(sctp-sack), OPTIONAL(sctp-heartbeat), OPTIONAL(sctp-heartbeat-ack), OPTIONAL(sctp-abort), OPTIONAL(sctp-shutdown), OPTIONAL(sctp-shutdown-ack), OPTIONAL(sctp-error), OPTIONAL(sctp-cookie-echo), OPTIONAL(sctp-cookie-ack), OPTIONAL(sctp-ecne), OPTIONAL(sctp-cwr), OPTIONAL(sctp-shutdown-complete), OPTIONAL(sctp-generic), 0, 0, 0, 0, 1, 2, 3, 4, 5, 6, 7 8, 9, 10, 11, 12, 13, 14) ; ; order ; STATIC(90%) | IRREGULAR(95,10%) West & Surtees Expires August 23, 2002 [Page 16] Internet-Draft SCTP Profile for EPIC February 2002 ; ; presence ; STATIC(70%) | IRREGULAR(19,30%) chunk-list-ir = LIST( 16 ; uses IP length 1, 8, -224 ; values for d, m & p 8, ; width of 'type' field OPTIONAL(sctp-data-ir), OPTIONAL(sctp-data-ir), OPTIONAL(sctp-data-ir), OPTIONAL(sctp-data-ir), OPTIONAL(sctp-init), OPTIONAL(sctp-init-ack), OPTIONAL(sctp-sack), OPTIONAL(sctp-heartbeat), OPTIONAL(sctp-heartbeat-ack), OPTIONAL(sctp-abort), OPTIONAL(sctp-shutdown), OPTIONAL(sctp-shutdown-ack), OPTIONAL(sctp-error), OPTIONAL(sctp-cookie-echo), OPTIONAL(sctp-cookie-ack), OPTIONAL(sctp-ecne), OPTIONAL(sctp-cwr), OPTIONAL(sctp-shutdown-complete), OPTIONAL(sctp-generic), 0, 0, 0, 0, 1, 2, 3, 4, 5, 6, 7 8, 9, 10, 11, 12, 13, 14) ; ; order ; IRREGULAR(95,100%) ; ; presence ; IRREGULAR(19,100%) ; ; DATA chunk ; sctp-data-co = VALUE(8,0,100%) ; type West & Surtees Expires August 23, 2002 [Page 17] Internet-Draft SCTP Profile for EPIC February 2002 data-flags STACK-TO-CONTROL(16) ; length sctp-tsn-co CONTEXT(stream-data-co,8) STATIC(80%) | IRREGULAR(3,20%) data-payload stream-data-co = sctp-sid-co sctp-ssn-co sctp-ppi-co sctp-data-ir = VALUE(8,0,100%) ; type data-flags STACK-TO-CONTROL(16) ; length sctp-tsn-ir CONTEXT(stream-data-ir,8) STATIC(80%) | IRREGULAR(3,20%) data-payload stream-data-ir = sctp-sid-ir sctp-ssn-ir sctp-ppi-ir data-flags = VALUE(5,0,100%) IRREGULAR(1,100%) ; U IRREGULAR(1,100%) ; B IRREGULAR(1,100%) ; E sctp-tsn-co = LSB(4,4,60%) | LSB(8,16,25%) | LSB(16,1024,10%) | IRREGULAR(32,5%) sctp-tsn-ir = IRREGULAR(32,100%) sctp-sid-co = STATIC(90%) | IRREGULAR(16,10%) West & Surtees Expires August 23, 2002 [Page 18] Internet-Draft SCTP Profile for EPIC February 2002 sctp-sid-ir = IRREGULAR(16,100%) sctp-ssn-co = LSB(4,4,60%) | LSB(8,16,25%) | LSB(16,1024,10%) | IRREGULAR(32,5%) sctp-ssn-ir = IRREGULAR(32,5%) sctp-ppi-co = STATIC(90%) | IRREGULAR(32,10%) sctp-ppi-ir = IRREGULAR(32,10%) data-payload = STACK-FROM-CONTROL(16) UNCOMPRESSED(16, 1,1,-16) ; d, m, p STACK-TO-CONTROL(16) PADDING(16,32,8,0) data-chunk-length data-chunk-length = IRREGULAR-PADDED(16,12,80%) | IRREGULAR(16,20%) ; ; INIT chunk ; sctp-init = VALUE(8,1,100%) ; type chunk-flags STACK-TO-CONTROL(16) ; length initiate-tag adv-rwnd stream-out stream-in initial-tsn init-params chunk-flags = STATIC(80%) | IRREGULAR(8,20%) intitiate-tag = IRREGULAR(32,100%) adv-rwnd = IRREGULAR(32,100%) West & Surtees Expires August 23, 2002 [Page 19] Internet-Draft SCTP Profile for EPIC February 2002 stream-out = IRREGULAR(16,100%) stream-in = IRREGULAR(16,100%) initial-tsn = IRREGULAR(32,100%) init-params = STACK-FROM-CONTROL(16) UNCOMPRESSED(16, 1,1,-20) ; d, m, p STACK-TO-CONTROL(16) PADDING(16,32,8,0) init-chunk-length init-chunk-length = IRREGULAR-PADDED(16,10,90%) | IRREGULAR(16,10%) ; ; INIT ACK Chunk ; sctp-init-ack = VALUE(8,2,100%) ; type chunk-flags STACK-TO-CONTROL(16) ; length initiate-tag adv-rwnd stream-out stream-in initial-tsn init-params ; ; SACK chunk ; sctp-sack = VALUE(8,3,100%) ; type chunk-flags IRREGULAR(16) ; length adv-rwnd West & Surtees Expires August 23, 2002 [Page 20] Internet-Draft SCTP Profile for EPIC February 2002 STACK-TO-CONTROL(16) ; gap count STACK-TO-CONTROL(16) ; dup. TSN count ROTATE(2,1) gap-list dup-tsn-list gap-list = LIST(16, 1, 32, 0, OPTIONAL(gap-entry), OPTIONAL(gap-entry), OPTIONAL(gap-entry), OPTIONAL(gap-entry), OPTIONAL(gap-entry), OPTIONAL(gap-entry), OPTIONAL(gap-entry), OPTIONAL(gap-entry)) ; ; order ; STATIC(80%) | IRREGULAR(24,20%) ; ; presence ; STATIC(50%) | IRREGULAR(8,50%) gap-entry = STATIC(50%) | IRREGULAR(16,50%) STATIC(50%) | IRREGULAR(16,50%) dup-tsn-list = LIST(16, 1, 32, 0, OPTIONAL(tsn-entry), OPTIONAL(tsn-entry), OPTIONAL(tsn-entry), OPTIONAL(tsn-entry), OPTIONAL(tsn-entry), OPTIONAL(tsn-entry), OPTIONAL(tsn-entry), OPTIONAL(tsn-entry)) ; ; order West & Surtees Expires August 23, 2002 [Page 21] Internet-Draft SCTP Profile for EPIC February 2002 ; STATIC(80%) | IRREGULAR(24,20%) ; ; presence ; STATIC(50%) | IRREGULAR(8,50%) tsn-entry = STATIC(50%) | IRREGULAR(32,50%) ; ; HEARTBEAT chunk ; sctp-heartbeat = VALUE(8,4,100%) ; type chunk-flags STACK-TO-CONTROL(16) UNCOMPRESSED(16,1,1,-4) STACK-TO-CONTROL(16) PADDING(16,32,8,0) IRREGULAR(16,100%) ; ; HEARTBEAT ACK chunk ; sctp-heartbeat-ack = VALUE(8,5,100%) ; type chunk-flags STACK-TO-CONTROL(16) UNCOMPRESSED(16,1,1,-4) STACK-TO-CONTROL(16) PADDING(16,32,8,0) IRREGULAR(16,100%) ; ; ABORT chunk West & Surtees Expires August 23, 2002 [Page 22] Internet-Draft SCTP Profile for EPIC February 2002 ; sctp-abort = VALUE(8,6,100%) ; type abort-flags STACK-TO-CONTROL(16) UNCOMPRESSED(16,1,1,-4) STACK-TO-CONTROL(16) PADDING(16,32,8,0) IRREGULAR(16,100%) abort-flags = VALUE(7,0,100%) IRREGULAR(1,100%) ; ; SHUTDOWN chunk ; sctp-shutdown = VALUE(8,7,100%) ; type chunk-flags VALUE(16,8,100%) ; length IRREGULAR(32,100%) ; ; SHUTDOWN ACK chunk ; sctp-shutdown-ack = VALUE(8,8,100%) ; type chunk-flags VALUE(16,4,100%) ; length ; ; ERROR chunk ; sctp-error = VALUE(8,9,100%) ; type West & Surtees Expires August 23, 2002 [Page 23] Internet-Draft SCTP Profile for EPIC February 2002 chunk-flags cause-list cause-list = LIST(16,1,1,-4, OPTIONAL(error-cause), OPTIONAL(error-cause), OPTIONAL(error-cause), OPTIONAL(error-cause)) ; ; order ; STATIC(99%) | IRREGULAR(8,1%) ; ; presence ; STATIC(50%) | IRREGULAR(4,50%) error-cause = cause-code STACK-TO-CONTROL(16) UNCOMPRESSED(16,1,1,-4) STACK-TO-CONTROL(16) PADDING(16,32,8,0) IRREGULAR(16,100%) cause-code = IRREGULAR-PADDED(16,4,99%) | IRREGULAR(16,1%) ; ; COOKIE ECHO chunk ; sctp-cookie-echo = VALUE(8,10,100%) ; type chunk-flags STACK-TO-CONTROL(16) UNCOMPRESSED(16,1,1,-4) West & Surtees Expires August 23, 2002 [Page 24] Internet-Draft SCTP Profile for EPIC February 2002 STACK-TO-CONTROL(16) PADDING(16,32,8,0) IRREGULAR(16,100%) ; ; COOKIE ACK chunk ; sctp-cookie-ack = VALUE(8,11,100%) ; type chunk-flags VALUE(16,4,100%) ; length ; ; these are reserved values, but not yet used. ; thus they are currently treated as generic chunk ; headers ; sctp-ecne = sctp-generic sctp-cwr = sctp-generic ; ; SHUTDOWN COMPLETE chunk ; sctp-shutdown-complete = VALUE(8,14,100%) ; type shutdown-complete-flags VALUE(16,4,100%) ; length shutdown-complete-flags = VALUE(7,0,100%) IRREGULAR(1,100%) ; ; Generic handler for any Type/Length/Value SCTP chunk ; header... ; sctp-generic = IRREGULAR(8,100%) ; type West & Surtees Expires August 23, 2002 [Page 25] Internet-Draft SCTP Profile for EPIC February 2002 chunk-flags STACK-TO-CONTROL(16) UNCOMPRESSED(16,1,1,-4) STACK-TO-CONTROL(16) PADDING(16,32,8,0) IRREGULAR(16,100%) 6. Security Considerations This draft describes a profile for the compression and decompression of SCTP/IPv4 headers. See [1] for the security issues raised by robust header compression. See [2] for the security issues raised by the use of EPIC. 7. Acknowledgements The authors would like to acknowledge the many people who have helped with issues relating to SCTP, ROHC and EPIC. These stalwarts include Carsten Bormann, Max Riegel, Christian Schmidt, Michael Tuexen, Richard Price, Rob Hancock, Paul Ollis, and Stephen McCann. References [1] 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 Zheng, H., "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [2] Price, R., Hancock, R., Ollis, P., Surtees, A. and West, M., "Framework for EPIC-lite", draft-ietf-rohc-epic-lite-01.txt (work in progress), February 2002. [3] Schmidt, C. and Tuexen, M., "Requirements for SCTP Compression", draft-ietf-rohc-sctp-reqs-00.txt (work in progress), February 2002. [4] Bradner, S., "The Internet Standards Process -- Revision 3", BCP West & Surtees Expires August 23, 2002 [Page 26] Internet-Draft SCTP Profile for EPIC February 2002 9, RFC 2026, October 1996. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and Paxson, V., "Stream Control Transmission Protocol", RFC 2960, October 2000. Authors' Addresses Mark A. West Siemens/Roke Manor Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK Phone: +44 (0)1794 833311 EMail: mark.a.west@roke.co.uk URI: http://www.roke.co.uk Abigail Surtees Siemens/Roke Manor Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK Phone: +44 (0)1794 833131 EMail: abigail.surtees@roke.co.uk URI: http://www.roke.co.uk West & Surtees Expires August 23, 2002 [Page 27] Internet-Draft SCTP Profile for EPIC February 2002 Appendix A. Pseudo-code for PADDING method COMPRESS (PADDING) var len, item, remainder, paddding, num_units, i item = top (control_data) len = value (item) if (length (item) <> l) then return false endif remainder = (len * 8) mod m padding = m - remainder num_units = padding / s if ((padding mod s) <> 0) then return false endif for i = 1 to num_units if (value (top (uncompressed_data, s)) = p) then pop (uncompressed_data, s, item) else return false endif end loop return true end COMPRESS West & Surtees Expires August 23, 2002 [Page 28] Internet-Draft SCTP Profile for EPIC February 2002 DECOMPRESS (PADDING) var len, item, remainder, paddding var num_units, i item = top (control_data) len = value (item) remainder = (len * 8) mod m padding = m - remainder num_units = padding / s for i = 1 to num_units push (uncompressed_data, s, p) end loop end DECOMPRESS BUILD (PADDING, 100%, format) end BUILD West & Surtees Expires August 23, 2002 [Page 29] Internet-Draft SCTP Profile for EPIC February 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. West & Surtees Expires August 23, 2002 [Page 30]