Network Working Group M. West Internet-Draft A. Surtees Expires: December 26, 2003 Siemens/Roke Manor June 27, 2003 SCTP Profile for EPIC draft-west-sctp-epic-01.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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This draft describes a profile for compressing SCTP/IP using the Robust Header Compression Formal Notation. 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 December 26, 2003 [Page 1] Internet-Draft SCTP Profile for EPIC June 2003 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 the Formal Notation 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 . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 25 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 25 References . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . 26 Full Copyright Statement . . . . . . . . . . . . . . . . 27 West & Surtees Expires December 26, 2003 [Page 2] Internet-Draft SCTP Profile for EPIC June 2003 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 the Formal Notation [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 formal notation input language. The framework takes a profile as its input. A profile describes the fields of a particular protocol header using the formal notation. This formal notation also describes how to compress each field using one or more of the fundamental methods defined in the formal notation. 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 formal notation and the process of generating packets, refer to [2]. It is assumed in this profile that Huffman encoding will be used to generate the indicator bits that enable packets to be decompressed correctly. 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 West & Surtees Expires December 26, 2003 [Page 3] Internet-Draft SCTP Profile for EPIC June 2003 user data encapsulated within SCTP DATA chunks. Stream 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. 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 December 26, 2003 [Page 4] Internet-Draft SCTP Profile for EPIC June 2003 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 December 26, 2003 [Page 5] Internet-Draft SCTP Profile for EPIC June 2003 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 5.1 Overview This section gives an overview of how the 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 December 26, 2003 [Page 6] Internet-Draft SCTP Profile for EPIC June 2003 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 'uncompressible' data. The process of compression is exactly the same as for any profile written in the formal notation. 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 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 in a label. This is because there is no length indication in the SCTP header, but the use of '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 West & Surtees Expires December 26, 2003 [Page 7] Internet-Draft SCTP Profile for EPIC June 2003 the case with the RTP sequence number in [1]. Therefore, it is 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, West & Surtees Expires December 26, 2003 [Page 8] Internet-Draft SCTP Profile for EPIC June 2003 each instance of a data-chunk in the list might be associated with a different stream. 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 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 West & Surtees Expires December 26, 2003 [Page 9] Internet-Draft SCTP Profile for EPIC June 2003 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 It is useful to define an additional encoding method for SCTP compression. This can be defined in the formal notation and its definition serves only to simplify the profile. The expansion into fundamental encoding methods could be put in every position in which it is used. West & Surtees Expires December 26, 2003 [Page 10] Internet-Draft SCTP Profile for EPIC June 2003 5.2.1 padding padding (data_len,d,m,l,p) ::= field (n) map (Field_Value, p, Null) where b = floor (data_len, d) * m n = mod (l - mod (b, l), l) d = divider to get length in bits m = multiplier to get length in bits l = overall size must be a multiple of l bits p = value of padding bits 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. It then computes how many blocks of padding should be present and their value. If this matches the data on the uncompressed data in the correct position in the header, then the padding is simply ignored. At the decompressor, the same calculation is performed on the length field. The padding is then put back in place in the header. 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 present. 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 in label data_len. This translates to the following encoding: padding(data_len,1,8,32,0) 5.3 The Profile ; ; These 3 encodings are the base methods that define the ; encoding of the IPv4/SCTP header ; sctp_ip_formats_ir ::= ordinary_huffman(sctp_ip_header_ir) West & Surtees Expires December 26, 2003 [Page 11] Internet-Draft SCTP Profile for EPIC June 2003 sctp_ip_formats_dyn ::= ordinary_huffman(sctp_ip_header_dyn) sctp_ip_formats_co ::= ordinary_huffman(sctp_ip_header_co) sctp_ip_header_ir ::= ip_header_ir sctp_header_ir header_crc sctp_ip_header_dyn ::= ip_header_dyn sctp_header_dyn header_crc sctp_ip_header_co ::= ip_header_co sctp_header_co header_crc ; ; The breakdown of field encodings for an IPv4 header ; ip_header_ir ::= inferred_ip_checksum ip_version ip_header_length ip_tos_dyn ip_ecn ip_length ip_id_dyn ip_reserved ip_dont_fragment_dyn ip_more_fragments ip_offset ip_time_to_live_dyn ip_protocol ip_checksum ip_source_address_ir ip_dest_address_ir ip_header_dyn ::= inferred_ip_checksum ip_version ip_header_length ip_tos_dyn ip_ecn ip_length ip_id_dyn ip_reserved ip_dont_fragment_dyn ip_more_fragments West & Surtees Expires December 26, 2003 [Page 12] Internet-Draft SCTP Profile for EPIC June 2003 ip_offset ip_time_to_live_dyn ip_protocol ip_checksum ip_source_address_co ip_dest_address_co ip_header_co ::= inferred_ip_checksum ip_version ip_header_length ip_tos_co ip_ecn ip_length ip_id_co ip_reserved ip_dont_fragment_co ip_more_fragments ip_offset ip_time_to_live_co ip_protocol ip_checksum ip_source_address_co ip_dest_address_co ; IP version (fixed as 4) ; ip_version ::= value(4,4) ; IP header length (fixed as 5) ; ip_header_length ::= value(4,5) ; IP TOS is a rarely changing field ; ip_tos_dyn ::= irregular (6) ip_tos_co ::= static ; ECN currently carried transparently. ; ip_ecn ::= irregular (2) ; save length for later ; ip_length ::= label (16,ip_len) ; Check that the IP ID is in network_byte order ; West & Surtees Expires December 26, 2003 [Page 13] Internet-Draft SCTP Profile for EPIC June 2003 ; 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_dyn ::= nbo (16) next_field (NBO_Flag) irregular (1) next_field (NBO_Field) irregular(16) ip_id_co ::= nbo (16) next_field (NBO_Flag) static next_field (NBO_Field) lsb (4,0) 90% / lsb(8,0) 9% / irregular(16) 1% ; Reserved flag assumed to be false (0) ; ip_reserved ::= value(1,0) ; DF can only change in IR/IR_DYN packets ; ip_dont_fragment_co ::= static ip_dont_fragment_dyn ::= irregular(1) ; MF is assumed to be false (0) ; ip_more_fragments ::= value(1,0) ; Offset is assumed to be (0) ; ip_offset ::= value(13,0) ; TTL is a rarely changing field ; ip_time_to_live_co ::= static 99% / irregular(8) 1% ip_time_to_live_dyn ::= irregular(8) ; Fixed value for the SCTP protocol ; ip_protocol ::= value(8,132) ; IP checksum is handled by inferred_ip_checksum ; ip_checksum ::= skip(16) West & Surtees Expires December 26, 2003 [Page 14] Internet-Draft SCTP Profile for EPIC June 2003 ; Source and destination addresses are set in an IR packet and ; do not change thereafter ; ip_source_address_ir ::= irregular(32) ip_source_address_co ::= static ip_dest_address_ir ::= irregular(32) ip_dest_address_co ::= static ; ; 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 ctp_chksum chunk_list_ir sctp_header_co ::= sport_co dport_co verif_tag_co sctp_chksum chunk_list_co ; Source and destination ports don't change after they are initially ; set in an IR packet ; sctp_source_port_ir ::= irregular(16) sctp_source_port_co ::= static sctp_source_port_ir ::= irregular(16) sctp_source_port_co ::= static ; Verification tag is a relatively rarely changing field ; West & Surtees Expires December 26, 2003 [Page 15] Internet-Draft SCTP Profile for EPIC June 2003 verif_tag_dyn ::= irregular(32) verif_tag_co ::= static 90% / irregular(32) 10% ; Checksum is just treated as an unpredictable 32_bit value ; sctp_chksum ::= irregular(32) ; The list of allowable chunk types. Each encoding in the list ; construct can be used only once per packet ; chunk_list_ir ::= list(ip_len, 1, 8, -256, [optional(sctp_data_ir), optional(sctp_data_ir), optional(sctp_data_ir), optional(sctp_data_ir), optional(sctp_init_ir), optional(sctp_init_ack_ir), optional(sctp_sack_ir), 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_sd_complete), optional(sctp_generic)]) sctp_chunks_order_co sctp_chunks_presence_co chunks_order_ir ::= irregular(95) chunks_presence_ir ::= irregular(19) chunk_list_co ::= list(ip_len, 1, 8, -256 [optional(sctp_data_co), optional(sctp_data_co), optional(sctp_data_co), optional(sctp_data_co), optional(sctp_init_co), optional(sctp_init_ack_co), optional(sctp_sack_co), optional(sctp_heartbeat), optional(sctp_heartbeat_ack), West & Surtees Expires December 26, 2003 [Page 16] Internet-Draft SCTP Profile for EPIC June 2003 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_sd_complete), optional(sctp_generic)]) sctp_chunks_order_co sctp_chunks_presence_co chunks_order_co ::= static 90% / irregular(95) 10% chunks_presence_co ::= static 70% / irregular(19) 30% ; ; DATA chunk ; sctp_data_ir ::= value(8,0) ; type data_flags label (16, data_len) ; length sctp_tsn_ir sctp_sid_ir sctp_ssn_ir sctp_ppi_ir data_payload data_chunk_length_ir sctp_data_co ::= value(8,0) ; type data_flags label (16, data_len) ; length sctp_tsn_co sctp_sid_co sctp_ssn_co sctp_ppi_co data_payload data_chunk_length_co data_flags ::= value(5,0) irregular(3) ; u, b, e sctp_tsn_ir ::= irregular(32) sctp_sid_ir ::= irregular(16) West & Surtees Expires December 26, 2003 [Page 17] Internet-Draft SCTP Profile for EPIC June 2003 sctp_ssn_ir ::= irregular(16) sctp_ppi_ir ::= irregular(32) sctp_tsn_co ::= lsb(4,4) 60% / lsb(8,16) 25% / lsb(16,1024) 10% / irregular(32) 5% sctp_sid_co ::= static 90% / irregular(16) 10% sctp_ssn_co ::= lsb(7,4) 60% / irregular(32) 40% sctp_ppi_co ::= static 90% / irregular(32) 10% data_payload ::= uncompressible(data_len,1,8,-128) padding(data_len,1,8,32,0) data_chunk_length_ir ::= next_field (data_len) irregular(16) data_chunk_length_co ::= next_field (data_len) irregular_padded(16,12) 80% / irregular(16) 20% ; ; INIT chunk ; sctp_init_ir ::= value(8,1) ; type chunk_flags_ir label (16, data_len) ; length initiate_tag adv_rwnd stream_out stream_in initial_tsn init_params init_chunk_length_ir sctp_init_co ::= value(8,1) ; type chunk_flags_co label (16, data_len) ; length initiate_tag adv_rwnd stream_out stream_in initial_tsn init_params init_chunk_length_co West & Surtees Expires December 26, 2003 [Page 18] Internet-Draft SCTP Profile for EPIC June 2003 chunk_flags_ir ::= irregular(8) chunk_flags_co ::= static 90% / irregular(8) 10% intitiate_tag ::= irregular(32) adv_rwnd ::= irregular(32) stream_out ::= irregular(16) stream_in ::= irregular(16) initial_tsn ::= irregular(32) init_params ::= uncompressible (data_len,1,8,-160) ; d, m, p padding(data_len,1,8,32,0) init_chunk_length_ir ::= next_field (data_len) irregular(16) init_chunk_length_co ::= next_field (data_len) irregular_padded(16,10) 90% / irregular(16) 10% ; ; INIT ACK Chunk ; sctp_init_ack_ir ::= value(8,2) ; type chunk_flags_ir label (16, data_len) ; length initiate_tag adv_rwnd stream_out stream_in initial_tsn init_params init_chunk_length_ir sctp_init_ack_co ::= value(8,2) ; type chunk_flags_co label(16, data_len) ; length initiate_tag adv_rwnd stream_out stream_in initial_tsn init_params West & Surtees Expires December 26, 2003 [Page 19] Internet-Draft SCTP Profile for EPIC June 2003 init_chunk_length_co ; ; SACK chunk ; sctp_sack_ir ::= value(8,3) ; type chunk_flags_ir irregular(16) ; length adv_rwnd label(16,gap_count) ; gap count label(16,dup_count) ; tsn count gap_list_ir dup_tsn_list_ir sctp_sack_co ::= value(8,3) ; type chunk_flags_co irregular(16) ; length adv_rwnd label(16,gap_count) ; gap count label(16,dup_count) ; tsn count gap_list_co dup_tsn_list_co gap_list_ir ::= list(gap_count, 1, 32, 0, [optional(gap_entry_ir), optional(gap_entry_ir), optional(gap_entry_ir), optional(gap_entry_ir), optional(gap_entry_ir), optional(gap_entry_ir), optional(gap_entry_ir), optional(gap_entry_ir)]) gap_order_ir gap_presence_ir gap_list_co ::= list(gap_count, 1, 32, 0, [optional(gap_entry_co), optional(gap_entry_co), optional(gap_entry_co), optional(gap_entry_co), optional(gap_entry_co), optional(gap_entry_co), optional(gap_entry_co), optional(gap_entry_co)]) gap_order_co gap_presence_co West & Surtees Expires December 26, 2003 [Page 20] Internet-Draft SCTP Profile for EPIC June 2003 gap_order_ir ::= irregular(24) gap_order_co ::= static 80% / irregular(24) 20% gap_presence_ir ::= irregular (8) gap_presence_co ::= static 50% / irregular (8) 50% gap_entry_ir ::= irregular(16) irregular(16) gap_entry_co ::= static 50% / irregular(16) 50% static 50% / irregular(16) 50% dup_tsn_list_ir ::= list(dup_count,1,32,0, [optional(tsn_entry_ir), optional(tsn_entry_ir), optional(tsn_entry_ir), optional(tsn_entry_ir), optional(tsn_entry_ir), optional(tsn_entry_ir), optional(tsn_entry_ir), optional(tsn_entry_ir)]) dup_order_ir dup_presence_ir dup_tsn_list_co ::= list(dup_count,1,32,0, [optional(tsn_entry_co), optional(tsn_entry_co), optional(tsn_entry_co), optional(tsn_entry_co), optional(tsn_entry_co), optional(tsn_entry_co), optional(tsn_entry_co), optional(tsn_entry_co)]) dup_order_co dup_presence_co dup_order_ir ::= irregular(24) dup_order_co ::= static 80% / irregular(24) 20% dup_presence_ir ::= irregular (8) dup_presence_co ::= static 50% / irregular (8) 50% tsn_entry_ir ::= irregular(32) West & Surtees Expires December 26, 2003 [Page 21] Internet-Draft SCTP Profile for EPIC June 2003 tsn_entry_co ::= static 50% / irregular(32) 50% ; ; HEARTBEAT chunk ; sctp_heartbeat ::= value(8,4) ; type chunk_flags_ir label(16,data_len) uncompressible(data_len,1,8,-32) padding(data_len,1,8,32,0) next_field(data_len) irregular(16) ; ; HEARTBEAT ACK chunk ; sctp_heartbeat_ack ::= value(8,5) ; type chunk_flags_ir label(16,data_len) uncompressible(data_len,1,8,-32) padding(data_len,1,8,32,0) next_field(data_len) irregular(16) ; ; ABORT chunk ; sctp_abort ::= value(8,6) ; type abort_flags label(16,data_len) uncompressible(data_len,1,8,-32) padding(data_len,1,8,32,0) next_field(data_len) irregular(16) abort_flags ::= value(7,0) irregular(1) ; ; SHUTDOWN chunk ; sctp_shutdown ::= value(8,7) ; type chunk_flags_ir value(16,8) ; length West & Surtees Expires December 26, 2003 [Page 22] Internet-Draft SCTP Profile for EPIC June 2003 irregular(32) ; ; shutdown ack chunk ; sctp_shutdown_ack ::= value(8,8) ; type chunk_flags_ir value(16,4) ; length ; ; ERROR chunk ; sctp_error_ir ::= value(8,9) ; type chunk_flags_ir label(16,data_len) cause_list cause_list_ir ::= list(data_len,1,8,-32, [optional(error_cause_ir), optional(error_cause_ir), optional(error_cause_ir), optional(error_cause_ir)]) cause_list_order_ir cause_list_presence_ir cause_list_co ::= list(data_len,1,8,-32, [optional(error_cause_co), optional(error_cause_co), optional(error_cause_co), optional(error_cause_co)]) cause_order_co cause_presence_co cause_order_ir ::= irregular(8) cause_order_co ::= static 99% / irregular(8) 1% cause_presence_ir ::= irregular(4) cause_presence_co ::= static 50% / irregular(4) 50% error_cause_ir ::= cause_code_ir label(cause_len,16) uncompressible(cause_len,1,8,-32) padding(cause_len,1,8,32,0) next_field(cause_len) West & Surtees Expires December 26, 2003 [Page 23] Internet-Draft SCTP Profile for EPIC June 2003 irregular(16) error_cause_co ::= cause_code_co label(cause_len,16) uncompressible(cause_len,1,8,-32) padding(cause_len,1,8,32,0) next_field(cause_len) irregular(16) cause_code_ir ::= irregular(16) cause_code_co ::= irregular_padded(16,4) 99% / irregular(16) 1% ; ; COOKIE ECHO chunk ; sctp_cookie_echo ::= value(8,10) ; type chunk_flags_ir label(16,data_len) uncompressible(data_len,1,8,-32) padding(data_len,1,8,32,0) next_field(data_len) irregular(16) ; ; COOKIE ACK chunk ; sctp_cookie_ack ::= value(8,11) ; type chunk_flags value(16,4) ; 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 ; West & Surtees Expires December 26, 2003 [Page 24] Internet-Draft SCTP Profile for EPIC June 2003 ; SHUTDOWN COMPLETE chunk ; sctp_sd_complete ::= value(8,14) ; type sd_complete_flags value(16,4) ; length sd_complete_flags ::= value(7,0) irregular(1) ; ; Generic handler for any Type/Length/Value SCTP chunk ; header... ; sctp_generic ::= irregular(8) ; type chunk_flags_ir label(16,data_len) uncompressible(data_len,1,8,-32) padding(data_len,1,8,32,0) next_field(data_len) irregular(16) 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 the Formal Notation. 7. Acknowledgements The authors would like to acknowledge the many people who have helped with issues relating to SCTP, ROHC and the formal notation. These stalwarts include Carsten Bormann, Max Riegel, Christian Schmidt, Michael Tuexen, Richard Price, Rob Hancock, 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 H. Zheng, "RObust Header Compression (ROHC): West & Surtees Expires December 26, 2003 [Page 25] Internet-Draft SCTP Profile for EPIC June 2003 Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [2] Price, R., Surtees, A. and M. West, "Formal Notation for Robust Header Compression ROHC-FN", draft-ietf-rohc-formal-notation- 01.txt (work in progress), March 2003. [3] Schmidt, C. and M. Tuexen, "Requirements for SCTP Compression", draft-ietf-rohc-sctp-reqs-02.txt (work in progress), February 2003. [4] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 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 V. Paxson, "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 December 26, 2003 [Page 26] Internet-Draft SCTP Profile for EPIC June 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). 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. This Internet-Draft will expire on December 26, 2003. West & Surtees Expires December 26, 2003 [Page 27]