Network Working Group Hongbin Liao Internet Draft Qian Zhang Expires: December 2002 Wenwu Zhu Microsoft Research Asia June, 2002 Generic Header Compression Notation for ROHC Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [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 obsolete by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft describes the framework of the generic header compression notation (ROHC-GN). The goal of Robust Header Compression (ROHC) is to develop generic header compression schemes that perform well over links with high error rates and long roundtrip times. ROHC will develop multiple compression schemes, for example, ROHC-RTP, ROHC-TCP [ROHC-TCP], ROHC-SCTP [ROHC-SCTP], etc. Our proposed generic header compression notation will describe the header fields that are to be compressed, and the information to be transmitted in the compressed header. Using this notation and the corresponding encoding methods, we can have a toolbox to standardize future ROHC profiles. Liao, Zhang, Zhu. [Page 1] draft-ietf-liao-rohc-notation-00.txt Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Introduction....................................................4 2. Terminology.....................................................4 3. Overview of ROHC-GN.............................................4 3.1 BNF input language for ROHC-GN..............................4 4. Notation of the uncompressed header.............................6 4.1 BITS........................................................7 4.2 VALUE.......................................................7 4.3 PADDING-F...................................................7 4.4 PADDING-T...................................................7 4.5 Out-of-order sequence and repeat sequence...................8 4.5.1 LIST-N.................................................8 4.5.2 LIST-0.................................................8 4.5.3 LIST-L.................................................8 4.6 ................................................9 4.7 Example notation of the uncompressed TCP header.............9 5. Notation of header compression.................................11 5.1 Structure of the compressed headers........................11 5.2 Notations for compressed header............................12 5.2.1 STATIC................................................12 5.2.2 IRREGULAR.............................................13 5.2.2.1 IRREGULAR-PADDED.................................13 5.2.3 VALUE.................................................13 5.2.4 LSB...................................................13 5.2.5 OFFSET................................................14 5.2.6 SCALE-FACTOR..........................................14 5.2.7 SCALE-REMAINDER.......................................14 5.2.8 NBO-FLAG..............................................15 5.2.9 NBO...................................................15 5.2.10 INFERRED.............................................15 5.2.11 CRC..................................................15 5.2.12 SUB-TREE-0...........................................16 5.2.13 SUB-TREE-N...........................................16 5.2.14 SUB-TREE-LEN.........................................16 5.3 Indicator generation methods...............................17 5.3.1 HUFFMAN...............................................17 5.3.2 P.....................................................17 5.4 Profile for compressed header of TCP/IP....................18 6. Security considerations........................................20 7. Acknowledgements...............................................20 8. References.....................................................20 9. Authors' addresses.............................................21 Liao, Zhang, Zhu. [Page 2] draft-ietf-liao-rohc-notation-00.txt Document History 00 June 18, 2002 First release. Liao, Zhang, Zhu. [Page 3] draft-ietf-liao-rohc-notation-00.txt 1. Introduction This draft describes a generic notation language for the ROHC [RFC3095] framework, ROHC generic header compression notation (ROHC- GN), which aims to clarify and simplify the compressed header format generation. The generic notation language describes the header fields that are compressed, and how to compress each of them. This draft is organized as follows: Chapter 2 Explains some of the terminologies used in this draft. Chapter 3 Gives an overview of ROHC generic header compression notation, ROHC-GN. Chapter 4 Gives notations for uncompressed fields, i.e. the fields which are compressed. Chapter 5 Gives notations for compression of header fields. 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 [RFC2119]. 3. Overview of ROHC-GN ROHC-GN is a generic notation language that describes header fields to be compressed and how they are compressed. Thus, ROHC-GN is composed of two parts: the notation for uncompressed (original) headers and the notation for compressed headers. The notation of uncompressed headers is used to clarify the terms and relations among different fields in the protocol headers. It also provides the way how to refer uncompressed fields. The notation of compressed header is used to specify how to compress the original fields, including the encoding methods used for each field. Thus, the result of this notation includes two kinds of information: one kind of information is the compressed value of a given field; the other kind of information is the indicator of which method is used if there is more than one encoding method for a given field. 3.1 BNF input language for ROHC-GN This section describes the BNF-based input language provided by ROHC-GN for the creation of new ROHC [RFC3095] profiles. Liao, Zhang, Zhu. [Page 4] draft-ietf-liao-rohc-notation-00.txt Similar as the one proposed in EPIC-LITE [EPIC], the language is designed to be flexible but at the same time easy to use without detailed knowledge of the mathematics underlying ROHC-GN. The only requirement for writing an efficient profile is a description of how the relevant protocol stack behaves. As with all versions of BNF, the description of the protocol is built up using the following two constructs: New BNF rule A new encoding method is created from existing ones by writing a new BNF rule for the encoding method Set of choices One or more encoding methods can be assigned to a given field by using the choice ("|") operator The detail notation for uncompressed structure and the compressed packet can be found in detail in the next 2 sections. The exact syntax of the BNF-based input language can itself be described using an existing version of BNF. A suitable variant is "Augmented BNF" (ABNF) as described in RFC-2234 [RFC2234]. For example, in ABNF the syntax for defining a new encoding method in terms of existing ones is as follows: = "=" 1*( ) = *( "|" ) Each instance of calls an encoding method that converts a certain number of uncompressed bits into a certain number of compressed bits. Note also that is white space, used to delimit the various encoding methods. An example of how to create a new encoding method is given below. An encoding method known as IPv6_Header is constructed from the basic encoding methods available in the library. This new method is designed to compress an entire IPv6 header. IPv6_Header_co = Version Traffic_Class_co ECT_Flag_co CE_Flag Flow_Label_co Payload_Length Next_Header Hop_Limit_co Source_Address_co Destination_Address_co Version = VALUE(4,6,100%) Liao, Zhang, Zhu. [Page 5] draft-ietf-liao-rohc-notation-00.txt Traffic_Class = STATIC(100%) ECT_Flag = STATIC(100%) CE_Flag = VALUE(1,0,99%) | VALUE(1,1,1%) . . . Each field in the IPv6 header is given a choice of possible encoding methods. This is very important since EPIC-LITE ensures that common encoding methods require fewer bits to carry the compressed data than rarely used encoding methods. For optimal compression, the probability should equal the percentage of time for which the encoding method is selected to compress the field. Note that there is no requirement for probabilities to add up to exactly 100%, as EPIC-LITE will automatically scale the probabilities by a constant factor if they do not. Note also that the BNF input language is designed to be both human- readable and machine-readable. If only one protocol stack needs to be compressed, the input language can simply be converted by hand directly to an implementation. However, since the input language provides a complete description of the protocol stack to be compressed, it is possible to compress headers using only the information contained in the BNF description and without any additional knowledge of the protocol stack. This means that it is possible to implement a protocol-independent compressor that can download a new ROHC [RFC3095] profile described in the BNF input language and immediately uses it to compress headers. 4. Notation of the uncompressed header This section gives the notation of the uncompressed (original) header, which tries to give a more formal definition of the uncompressed packet header. After that, the notation of compressed header use labels defined in this section to refer the corresponding fields in the uncompressed header. Note that this notation is only for descriptive purpose and it will not affect the efficiency of the header compression. A header is the control information of a message or packet of data. Generally, the information of header is organized as a tree. The root of this tree is the header itself. Each node is composed of its child nodes. For example, TCP Sequence Number is the child node of TCP header. In most cases, a node's children further consist of a sequence of child nodes in which each one has a different type and/or name and appears in the specified order, for example, TCP source port and TCP Destination Port, etc. However, there also exist some child nodes which may appear in any order, for example, options in the TCP Options. Moreover, there exist some nodes with the same Liao, Zhang, Zhu. [Page 6] draft-ietf-liao-rohc-notation-00.txt type and/or name which occur multi-times, for example, NOP, SACK- BLOCK, etc. We refer to the later two cases as 'out-of-order- sequence' and 'repeat-sequence' respectively and the former one as 'in-order-sequence'. The basic idea of the notation for uncompressed header is expressing the header in a tree and gives the method how to define a node. Moreover, the notation also gives the method how to refer each node in this tree. The syntax of each node definition is given using ABNF as defined in RFC-2234 [RFC2234]. Note that each of the definition method may have one or more parameters of the following type: A non-negative integer (specified as decimal, binary or hex). Binary values are prefixed by 0b and hex values are preceded by 0x. A non-negative integer used to indicate the length of the field being compressed. The name of the node. Defined later. 4.1 BITS ABNF notation: "BITS(" ")" is the length in bits of the node. 4.2 VALUE ABNF notation: "VALUE(" "," ")" is the value of node and is the length in bits of the node. 4.3 PADDING-F ABNF notation: "F-PADDING(" "," "," "," ")" The node specified by is aligned on bits, is the padded value which length in bits is . The padded value is added at the front of the node's value. 4.4 PADDING-T ABNF notation: "T-PADDING(" "," "," "," ")" Liao, Zhang, Zhu. [Page 7] draft-ietf-liao-rohc-notation-00.txt The node specified by is aligned on bits, the padded value is which length in bits is . The padded value is added at the tail of the node's value. 4.5 Out-of-order sequence and repeat sequence This section gives the notation of out-of-order sequence and repeat sequence. Depending on how to determine the end of the sequence, there are 3 kinds of notation. 4.5.1 LIST-N ABNF notation: "LIST-N(" "," "," *("," ) ")" The node is composed of a list of nodes (we will refer them as sub-nodes) which occur in any order, and each sub-node of them may occurs 0 or more times. The is the node which value specifies the number of sub-nodes in the list. The rest s are the possible sub-nodes of the list. Furthermore, the first specify a default node definition if a sequence of bits in the original header cannot match any other node definition. 4.5.2 LIST-0 ABNF notation: "LIST-0(" "," "," *("," ) ")" The node is composed of a list of nodes (we will refer them as sub-nodes) which occur in any order, and each sub-node of them may occurs 0 or more times. The first specifies the sub-node which is used as the flag of the ending of the list. The rest s are the possible sub-nodes of the list. Furthermore, the second specify a default node definition if a sequence of bits in the original header cannot match any other node definition (including the first .) 4.5.3 LIST-L ABNF notation: "LIST-L(" "," "," *("," ) ")" The node is composed of a list of nodes (we will refer them as sub-nodes) which occur in any order, and each sub-node of them may occurs 0 or more times. The specifies the maximum length in octets of the node. The following s are the possible sub- nodes of the list. Furthermore, the first specify a Liao, Zhang, Zhu. [Page 8] draft-ietf-liao-rohc-notation-00.txt default node definition if a sequence of bits in the original header cannot match any other node definition. 4.6 ABNF notation: *("." ) *1("[" "]") is used to reference the node, which is a sequence of separated by "." with or without the tailing "[" "]". is used to give the index number of sub-nodes in out- of-order sequence and repeat-sequence. 4.7 Example notation of the uncompressed TCP header This section gives an example notation of the uncompressed TCP header. The following is the notation of uncompressed TCP header: tcp := sport dport seqno ackno off reversed ecn control window checksum urgent PADDING-T(options,32,0,8) sport := BITS(16) dport := BITS(16) seqno := BITS(32) ackno := BITS(32) off := BITS(4) reserved := BITS(4) ecn := cwr ece cwr := BITS(1) ece := BITS(1) control := urg ack psh rst Liao, Zhang, Zhu. [Page 9] draft-ietf-liao-rohc-notation-00.txt syn fin urg := BITS(1) ack := BITS(1) psh := BITS(1) rst := BITS(1) syn := BITS(1) fin := BITS(1) window := BITS(16) checksum := BITS(16) urgent := BITS(16) options := LIST-0(opt-end, opt-gen, opt-nop, opt-mss, opt-wscale, opt-sack-permitted, opt-sack, opt-ts) opt-gen := opt-type opt-len LIST-N(opt-gen.opt-len - 2, BITS(8)) opt-end := VALUE(0,8) opt-nop := VALUE(1,8) opt-mss := VALUE(2,8) VALUE(4,8) mss mss := BITS(16) opt-wscale := VALUE(3,8) VALUE(3,8) wscale wscale := BITS(8) opt-sack-permitted := VALUE(4,8) VALUE(2,8) opt-sack := VALUE(5,8) sack-nblocks sacks sack-nblocks := BITS(8) sacks := LIST-N((opt-sack.sack-nblocks-2)/8), sack-block) sack-block := lblock rblock lblock := BITS(32) rblock := BITS(32) opt-ts := VALUE(8,8) VALUE(10,8) tsval tsecho Liao, Zhang, Zhu. [Page 10] draft-ietf-liao-rohc-notation-00.txt tsval := BITS(32) tsecho := BITS(32) The following are some examples of references to the nodes in the uncompressed TCP header: "tcp.seqno" the Sequence Number in the TCP header "tcp.options. opt-gen[0]" the first TCP option in the TCP header (since tcp-opt-generic is default the node definition in tcp-options.) "tcp. options.opt-end[0]" the first TCP Ending option in the TCP header (if it's guaranteed that there will at most one occurrence of this kind of node in out- of-order sequence and repeat-sequence, the above expression can be abbreviated as "tcp.options.opt-end".) "tcp.options.opt-nop[2]" the third occurrence of the TCP NOP option (if it exists) in the TCP header 5. Notation of header compression This gives the notation of header compression, which will decide how to compress each node in the header tree and decide what kind of data need transmitting. In general, there are two kinds of data to be transmitted. One kind of data is the encoded value of node using one of encoding methods. The other kind of data is the indicator which tells the decompressor which encoding method has been used to encode the value of node. 5.1 Structure of the compressed headers Our proposed compressed header structure extends the one proposed in [EPIC] to a more general format by introducing the concept of hierarchy. At the top level, each compressed header can be divided into also two parts: the indicator flags and the (sub) compressed headers. The indicator flags contain 0 or more bits and specify how to decompress those (sub) compressed header. The (sub) compressed header may be another level of compressed header or just the compressed value of the record. The structure of the proposed compressed header structure can be illustrated as follows: +-------------------+ | compressed header | +-------------------+ | +--------------+--------------------------+ | | | Liao, Zhang, Zhu. [Page 11] draft-ietf-liao-rohc-notation-00.txt +-----+ +--------------------+ +--------------------+ |flags| |(sub) comp. header 1| ... |(sub) comp. header n| +-----+ +--------------------+ +--------------------+ | +--------------+--------------------------+ | | | +-----------+ +-----------------------+ +-----------------------+ |(sub) flags| |(sub-sub)comp. header 1|... |(sub-sub)comp. header n| +-----------+ +-----------------------+ +-----------------------+ | +--------------------------+ | ... | With the proposed compressed header structure, the global format set of Huffman compressed, which contains all possible combinations of compressed methods of every field, is split into several format sets which is associated with each (sub) compressed header, and each format set can be tweaked into a manageable size. The complexity of finding indicator flags from compressing method of each field and vice versa can be alleviated in a divide-and-conquer way. The indicator flags specify how each field in the uncompressed header has been compressed, whilst the compressed fields contain enough information to transmit each field from the compressor to the decompressor. This information might be the entire uncompressed field, it might be LSBs (Least Significant Bits) of the uncompressed field etc. 5.2 Notations for compressed header The syntax of each encoding method is given using ABNF as defined in RFC-2234 [RFC2234]. Note that each of the notations may have one or more parameters of the following type: A non-negative integer (specified as decimal, binary or hex). Binary values are prefixed by 0b and hex values are preceded by 0x. An integer (positive or negative) The reference to node in the uncompressed header tree. The name of the encoding method including all parameters. 5.2.1 STATIC ABNF notation: "STATIC(" ")" The STATIC encoding method can be used when the node of the original header does not change relative to the context. If a field is Liao, Zhang, Zhu. [Page 12] draft-ietf-liao-rohc-notation-00.txt STATIC then no information concerning the field need be transmitted in the compressed header. The only parameter for the STATIC encoding method is the reference to the node of the original header. 5.2.2 IRREGULAR ABNF notation: "IRREGULAR(" ")" The IRREGULAR encoding method is used when the field cannot be compressed relative to the context, and hence must be transmitted in full in the compressed header. The IRREGULAR encoding method has an expression parameter to reference to the node in the original header. A modified version of IRREGULAR encoding is given below: 5.2.2.1 IRREGULAR-PADDED ABNF notation: "IRREGULAR-PADDED(" "," ")" The IRREGULAR-PADDED encoding method compresses any node that is large in terms of number of bits but has a small actual value (and hence the most significant bits are zero). The encoding method transmits a certain number of LSBs (Least Significant Bits) of the field. The first parameter gives the reference to the node in the original header, whilst the next parameter specifies the number of LSBs to be transmitted in the compressed header. The bits not transmitted are all taken to be 0 by the decompressor. The IRREGULAR-PADDED encoding method is useful for compressing fields that take small integer values in most cases. 5.2.3 VALUE ABNF notation: "VALUE(" ")" The VALUE encoding method can be used to transmit one particular value for a node. It is followed by parameters to give the reference to the node in the original header. 5.2.4 LSB ABNF notation: "LSB(" "," "," ")" Liao, Zhang, Zhu. [Page 13] draft-ietf-liao-rohc-notation-00.txt The LSB encoding method compresses the node by transmitting only its LSBs (Least Significant Bits). The first parameter gives reference to the node in the original header. The second parameter indicates the number of LSBs to transmit in the compressed header. The third parameter is the offset of the LSBs: it describes whether the decompressor should interpret the LSBs as increasing or decreasing the field value contained in its context. To illustrate how the second parameter works, suppose that k LSBs are transmitted with offset p. The decompressor uses these LSBs to replace the k LSBs of the value of this field stored in the context (val), and then adds or subtracts multiples of 2^k so that the new field value lies between (val - p) and (val - p + 2^k - 1). In particular, if p = 0 then the field value can only stay the same or increase. If p = -1 then it can only increase, whereas if p = 2^k then it can only decrease. Recall that for robustness the compressor can store r values for each field in its context. If this is the case then enough LSBs are transmitted so that the decompressor can reconstruct the correct field value, no matter which of the r values it has stored in its context. This is equivalent to Window-based LSB encoding as described in ROHC [RFC3095]. 5.2.5 OFFSET ABNF notation: "OFFSET(" "," "," ")" The OFFSET method encodes the difference between the first parameter and the second parameter, which are two references to the nodes in the original header. The third parameter is the number of bits of the difference to be transmitted to the decompressor. 5.2.6 SCALE-FACTOR ABNF notation: "SCALE-FACTOR(" "," ")" The first parameter gives the reference to the node in the original header. Suppose this node has value v. The second parameter specifies the scale s. The SCALE-FACTOR method gets the scaled value of v when v is divided by s. 5.2.7 SCALE-REMAINDER ABNF notation: "SCALE-REMAINER(" "," ")" Liao, Zhang, Zhu. [Page 14] draft-ietf-liao-rohc-notation-00.txt The first parameter gives the reference to the node in the original header. Suppose this node has value v. The second parameter specifies the scale s. The SCALE-REMAINDER method gets the remainder value of v when v is divided by s. 5.2.8 NBO-FLAG ABNF notation: "NBO-FLAG(" ")" NBO-FLAG gets a Boolean value, whether the node referenced by the parameter is in Network Byte Order. 5.2.9 NBO ABNF notation: "NBO(" ")" NBO returns value of the node referenced by the parameter in Network Byte Order. 5.2.10 INFERRED ABNF notation: "INFERRED(" ")" INFERRED encoding method can be used when the node referenced by the first parameter can be inferred from other information. 5.2.11 CRC ABNF notation: "CRC(" ")" The CRC encoding method generates a CRC checksum calculated across the entire uncompressed header. At the decompressor this CRC is used to validate that correct decompression has occurred. Note that it is possible for different header formats to have different amounts of CRC protection, so extra CRC bits can be allocated to protect important context-updating information. This is illustrated in the example below: CRC(3,99%) | ; Checksum Coverage CRC(7,1%) The uncompressed header is nodeed in the crc_static and crc_dynamic variables. Note that the fields that either never change or only change in the IR packet are placed in crc_static, and the remaining fields are placed in crc_dynamic. The CRC is calculated over crc_static + crc_dynamic, with the static fields placed first to speed up computation. In general an EPIC-LITE profile can use any CRC length for which a Liao, Zhang, Zhu. [Page 15] draft-ietf-liao-rohc-notation-00.txt CRC polynomial has been explicitly defined. The following CRC lengths are currently supported: 3-bit: C(x) = 1 + x + x^3 6-bit: C(x) = 1 + x + x^3 + x^4 + x^6 7-bit: C(x) = 1 + x + x^2 + x^3 + x^6 + x^7 8-bit: C(x) = 1 + x + x^2 + x^8 10-bit: C(x) = 1 + x + x^4 + x^5 + x^9 + x^10 12-bit: C(x) = 1 + x + x^2 + x^3 + x^11 + x^12 16-bit: C(x) = 1 + x^2 + x^15 + x^16 5.2.12 SUB-TREE-0 ABNF notation: "SUB-TREE-0(" "," *("," ) ")" SUB-TREE-0 encoding method tries to compress a sequence of records with one ending flag. For example, TCP Options field is a sequence of tcp options with END as the ending flag. The first parameter specifies the indicator flag, which will give the information which kind of node occurs in the sequence and their order. The following parameters are the possible kinds (or types) of node which may occur in the sequence. The second parameter serves as the ending flag of the sequence. 5.2.13 SUB-TREE-N ABNF notation: "SUB-TREE-N(" "," ")" SUB-TREE-N encoding method try to compress a sequence of the same type of records with a length field which is defined somewhere. For example, CSRC list entries and SACK blocks can be used with this method. The first parameter specifies the indicator flag, which will give the occurrences of the node specified by the second parameter. The second parameter gives the type of node which occurs in the sequence. 5.2.14 SUB-TREE-LEN ABNF notation: "SUB-TREE-LEN(" "," *("," ) ")" SUB-TREE-0 encoding method tries to compress a sequence of records, where the end of the sequence is determined by the length of the Liao, Zhang, Zhu. [Page 16] draft-ietf-liao-rohc-notation-00.txt uncompressed nodes, for example, the sequence of SCTP chunks in the SCTP packets. The first parameter specifies the indicator flag, which will give the information which kind of node occurs in the sequence and their order. The following parameters are the possible kinds (or types) of node which may occur in the sequence. 5.3 Indicator generation methods In compressed header, the indicator tells the decompressor which encoding method is used to encode which node in the original header. ItÆs dependent from the encoding methods. The most efficient way to generate the indicator is using Huffman code, giving the accurate probability of each method on each node and generating the global indicator. However, for out-of-order sequence and repeat sequence, that means the notation has to enumerate all possible cases. It may result inefficiency and complex. Instead using a global indicator, ROHC-NG solve this problem by allowing sub-node itself generate indicator for its sub-tree. The up-level indicator only counts the probability of the sub-node itself instead of all nodes on its sub- tree. The following library contains the indicator generation methods based on Huffman code. The syntax of each indicator generation method is given using ABNF as defined in RFC-2234 [RFC2234]. Note that each of the methods may have one or more parameters of the following type: The probability of the encoding method of the given node in the original header. 5.3.1 HUFFMAN ABNF notation: "HUFFMAN(" *("," ) ")ö HUFFMAN methods generates the Huffman prefix based the probabilities give by the following encoding methods. Each encoding method is considered as an independent condition from others. 5.3.2 P ABNF notation: "P(" *("," ) ")" P method gives the probability of the encoding methods specified by the following parameters, i.e. the probability of all of the Liao, Zhang, Zhu. [Page 17] draft-ietf-liao-rohc-notation-00.txt following encoding methods are satisfied is . If there is no encoding method specified, it means 'otherwise' case. Even though we only provide indicator generation methods based on Huffman code, ROHC-NG allows other indicator generation methods. 5.4 Profile for compressed header of TCP/IP This section describes an example profile for the compressed header of TCP/IP. Note that the probabilities listed for each encoding method are initial estimates only. These need to be refined with more accurate values from genuine TCP/IP streams. The profile for TCP/IP compression is given below: ctcp := ctcp-flags STATIC(tcp.sport) STATIC(tcp.dport) cseqno cackno INFERRED(off) IRREGULAR(reserved) IRREGULAR(tcp.ecn) ccontrol cwindow IRREGULAR(tcp.checksum) curgent coptions ctcp-flags := HUFFMAN(pseqnack, pcontrol, pwindow, purgent, poptions) pseqnack := P(45%, LSB(tcp.seqno,14,4096), LSB(tcp.ackno,8,63)) | P(45%, LSB(tcp.seqno,8,64), LSB(tcp.ackno,14,4096)) | P(10%) seqack-flag seqack-flag := P(LSB(tcp.seqno,8,63),5%) | P(LSB(tcp.seqno,14,4096),80%) | P(LSB(tcp.seqno,20,16384),10%) | P(IRREGULAR(tcp.seqno),5%) P(LSB(tcp.ackno,8,63),5%) | P(LSB(tcp.ackno,14,4096),80%) | P(LSB(tcp.ackno,20,16384),10%) | P(IRREGULAR(tcp.ackno),5%) pcontrol := P(90%, STATIC(tcp.control.urg)) | P(10%, IRREGULAR(tcp.control.urg)) P(90%, STATIC(tcp.control.ack)) | P(10%, IRREGULAR(tcp.control.ack)) P(90%, STATIC(tcp.control.psh)) | P(10%, IRREGULAR(tcp.control.psh)) Liao, Zhang, Zhu. [Page 18] draft-ietf-liao-rohc-notation-00.txt P(90%, STATIC(tcp.control.rst)) | P(10%, IRREGULAR(tcp.control.rst)) P(90%, STATIC(tcp.control.syn)) | P(10%, IRREGULAR(tcp.control.syn)) P(90%, STATIC(tcp.control.fin)) | P(10%, IRREGULAR(tcp.control.fin)) purgent := P(90%, STATIC(tcp.urgent)) | P(10%, IRREGULAR(tcp.urgent)) poptions := P(50%,tcp.options) | P(50%) cseqno := LSB(tcp.seqno,8,63) | LSB(tcp.seqno,14,4096) | LSB(tcp.seqno,20,16384) | IRREGULAR(tcp.seqno) cackno := LSB(tcp.ackno,8,63) | LSB(tcp.ackno,14,4096) | LSB(tcp.ackno,20,16384) | IRREGULAR(tcp.ackno) ccontrol := STATIC(tcp.control.urg) | IRREGULAR(tcp.control.urg) STATIC(tcp.control.ack) | IRREGULAR(tcp.control.ack) STATIC(tcp.control.psh) | IRREGULAR(tcp.control.psh) STATIC(tcp.control.rst) | IRREGULAR(tcp.control.rst) STATIC(tcp.control.syn) | IRREGULAR(tcp.control.syn) STATIC(tcp.control.fin) | IRREGULAR(tcp.control.fin) cwindow := STATIC(tcp.window) | LSB(tcp.window,12,63) | IRREGULAR(tcp.window) curgent := STATIC(tcp.urgent) | IRREGULAR(tcp.urgent) coptions := SUBTREE-0(coptions-flags, copt-gen, copt-end, copt-nop, copt-mss, copt-wscale, copt-sack-permitted, copt-sack, copt-ts) copt-gen := IRREGULAR(opt-gen) copt-end := STATIC(opt-end) copt-opt := STATIC(opt-opt) copt-mss := IRREGULAR(opt-mss.mss) copt-wscale := IRREGULAR(opt-wscale.wscale) copt-sack-permitted := STATIC(opt-sack-permitted) copt-sack := SUBTREE-N(copt-sack-flags,copt-sack-block) copt-ts := copt-ts-flags LSB(opt-ts.tsval,12,0) | LSB(opt-ts.tsval,16,0) | IRREGULAR(opt-ts.tsval) LSB(opt-ts.tsecho,12,0) | LSB(opt-ts.tsecho,16,0) | IRREGULAR(opt-ts.tsecho) Liao, Zhang, Zhu. [Page 19] draft-ietf-liao-rohc-notation-00.txt coptions-flags := LIST-0(copt-end-flag, copt-gen-flag, copt-nop-flag, copt-mss-flag, copt-wscale-flag, copt-sack-permitted-flag, copt-sack-flag, copt-ts-flag) copt-end-flag := VALUE(0,1) copt-nop-flag := VALUE(2,2) copt-sack-flag := VALUE(12,4) copt-ts-flag := VALUE(13,4) copt-mss-flag := VALUE(28,5) copt-wscale-flag := VALUE(29,5) copt-sack-permitted-flag := VALUE(30,5) copt-gen-flag := VALUE(31,5) copt-sack-flags := LSB(opt-sack.sack-nblocks, 2, 0) # BLOCK 0 copt-sack-block[0] := OFFSET(opt-sack.sack-block[0].lblock, tcp.ackno) OFFSET(opt-sack.sack-block[0].rblock, opt-sack.sack-block[0].lblock) # BLOCK n (n > 0) copt-sack-block[n] := OFFSET(opt-sack.sack-block[n].lblock, opt-sack.sack-block[n-1].rblock) OFFSET(opt-sack.sack-block[n].rblock, opt-sack.sack-block[n].lblock) 6. Security considerations ROHC-GN works with the corresponding encoding methods to generate compressed header formats for direct use in ROHC profiles. Consequently the security considerations for ROHC-GN inherit those of ROHC. 7. Acknowledgements Thanks to Mark A. West (mark.a.west@roke.co.uk) Lars-Erik Jonsson (EPL) (Lars-Erik.Jonsson@epl.ericsson.se) Mikael Degermark (micke@CS.Arizona.EDU) for valuable discussion in the ROHC mailing list. 8. References [RFC3095] Bormann (ed.), et al., "RObust Header Compression (ROHC)", RFC 3095, July 2001. Liao, Zhang, Zhu. [Page 20] draft-ietf-liao-rohc-notation-00.txt [ROHC-TCP] Q. Zhang et al., "TCP/IP Header Compression for ROHC (ROHC-TCP)" , Internet Draft (work in progress), April, 2002. [ROHC-SCTP] "Requirements for RoHC IP/SCTP Robust Header Compression (01)" , Internet Draft (work in progress), April, 2002. [EPIC] Richard Price et al, "Framework for EPIC-LITE", , Internet Draft (work in progress), Feb. 2002. [RFC2234] D. Crocker, Ed., P. Overell, Augmented BNF for Syntax Specifications: ABNF, RFC 2234, 1997. 9. Authors' addresses HongBin Liao Tel: +86 10 62617711-3156 Email: i-hbliao@microsoft.com Qian Zhang Tel: +86 10 62617711-3135 Email: qianz@microsoft.com Wenwu Zhu Tel: +86 10 62617711-5405 Email: wwzhu@microsoft.com Microsoft Research Asia Beijing Sigma Center No.49, Zhichun Road, Haidian District Beijing 100080, P.R.C. Liao, Zhang, Zhu. [Page 21]