< draft-ietf-rohc-formal-notation-12.txt   draft-ietf-rohc-formal-notation-13.txt >
Robust Header Compression R. Finking Robust Header Compression R. Finking
Internet-Draft Siemens/Roke Manor Internet-Draft Siemens/Roke Manor
Intended status: Standards Track G. Pelletier Intended status: Standards Track G. Pelletier
Expires: May 25, 2007 Ericsson Expires: May 5, 2007 Ericsson
November 21, 2006 November 2006
Formal Notation for Robust Header Compression (ROHC-FN) Formal Notation for Robust Header Compression (ROHC-FN)
draft-ietf-rohc-formal-notation-12 draft-ietf-rohc-formal-notation-13
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 25, 2007. This Internet-Draft will expire on May 5, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2006).
Abstract Abstract
This document defines ROHC-FN (RObust Header Compression - Formal This document defines ROHC-FN (RObust Header Compression - Formal
Notation): a formal notation to specify field encodings for Notation): a formal notation to specify field encodings for
compressed formats when defining new profiles within the ROHC compressed formats when defining new profiles within the ROHC
framework. ROHC-FN offers a library of encoding methods that are framework. ROHC-FN offers a library of encoding methods that are
often used in ROHC profiles and can thereby help simplifying future often used in ROHC profiles and can thereby help simplifying future
profile development work. profile development work.
skipping to change at page 2, line 37 skipping to change at page 2, line 37
4.7.3. Boolean Literals . . . . . . . . . . . . . . . . . . . 21 4.7.3. Boolean Literals . . . . . . . . . . . . . . . . . . . 21
4.7.4. Boolean Operators . . . . . . . . . . . . . . . . . . 21 4.7.4. Boolean Operators . . . . . . . . . . . . . . . . . . 21
4.7.5. Comparison Operators . . . . . . . . . . . . . . . . . 22 4.7.5. Comparison Operators . . . . . . . . . . . . . . . . . 22
4.8. Comments . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.8. Comments . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.9. "ENFORCE" Statements . . . . . . . . . . . . . . . . . . . 23 4.9. "ENFORCE" Statements . . . . . . . . . . . . . . . . . . . 23
4.10. Formal Specification of Field Lengths . . . . . . . . . . 24 4.10. Formal Specification of Field Lengths . . . . . . . . . . 24
4.11. Library of Encoding Methods . . . . . . . . . . . . . . . 25 4.11. Library of Encoding Methods . . . . . . . . . . . . . . . 25
4.11.1. uncompressed_value . . . . . . . . . . . . . . . . . . 25 4.11.1. uncompressed_value . . . . . . . . . . . . . . . . . . 25
4.11.2. compressed_value . . . . . . . . . . . . . . . . . . . 26 4.11.2. compressed_value . . . . . . . . . . . . . . . . . . . 26
4.11.3. irregular . . . . . . . . . . . . . . . . . . . . . . 27 4.11.3. irregular . . . . . . . . . . . . . . . . . . . . . . 27
4.11.4. static . . . . . . . . . . . . . . . . . . . . . . . . 27 4.11.4. static . . . . . . . . . . . . . . . . . . . . . . . . 28
4.11.5. lsb . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.11.5. lsb . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.11.6. crc . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.11.6. crc . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.12. Definition of Encoding Methods . . . . . . . . . . . . . . 30 4.12. Definition of Encoding Methods . . . . . . . . . . . . . . 30
4.12.1. Structure . . . . . . . . . . . . . . . . . . . . . . 30 4.12.1. Structure . . . . . . . . . . . . . . . . . . . . . . 31
4.12.2. Arguments . . . . . . . . . . . . . . . . . . . . . . 38 4.12.2. Arguments . . . . . . . . . . . . . . . . . . . . . . 38
4.12.3. Multiple Formats . . . . . . . . . . . . . . . . . . . 39 4.12.3. Multiple Formats . . . . . . . . . . . . . . . . . . . 39
4.13. Profile-specific Encoding Methods . . . . . . . . . . . . 41 4.13. Profile-specific Encoding Methods . . . . . . . . . . . . 42
5. Security considerations . . . . . . . . . . . . . . . . . . . 41 5. Security considerations . . . . . . . . . . . . . . . . . . . 42
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 42 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 42
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.1. Normative References . . . . . . . . . . . . . . . . . . . 43 9.1. Normative References . . . . . . . . . . . . . . . . . . . 43
9.2. Informative References . . . . . . . . . . . . . . . . . . 43 9.2. Informative References . . . . . . . . . . . . . . . . . . 44
Appendix A. Formal Syntax of ROHC-FN . . . . . . . . . . . . . . 43 Appendix A. Formal Syntax of ROHC-FN . . . . . . . . . . . . . . 44
Appendix B. Bit-level Worked Example . . . . . . . . . . . . . . 45 Appendix B. Bit-level Worked Example . . . . . . . . . . . . . . 46
B.1. Example Packet Format . . . . . . . . . . . . . . . . . . 46 B.1. Example Packet Format . . . . . . . . . . . . . . . . . . 46
B.2. Initial Encoding . . . . . . . . . . . . . . . . . . . . . 46 B.2. Initial Encoding . . . . . . . . . . . . . . . . . . . . . 47
B.3. Basic Compression . . . . . . . . . . . . . . . . . . . . 47 B.3. Basic Compression . . . . . . . . . . . . . . . . . . . . 48
B.4. Inter-packet compression . . . . . . . . . . . . . . . . . 49 B.4. Inter-packet compression . . . . . . . . . . . . . . . . . 50
B.5. Specifying Initial Values . . . . . . . . . . . . . . . . 50 B.5. Specifying Initial Values . . . . . . . . . . . . . . . . 51
B.6. Multiple Packet Formats . . . . . . . . . . . . . . . . . 51 B.6. Multiple Packet Formats . . . . . . . . . . . . . . . . . 52
B.7. Variable Length Discriminators . . . . . . . . . . . . . . 53 B.7. Variable Length Discriminators . . . . . . . . . . . . . . 54
B.8. Default encoding . . . . . . . . . . . . . . . . . . . . . 56 B.8. Default encoding . . . . . . . . . . . . . . . . . . . . . 57
B.9. Control Fields . . . . . . . . . . . . . . . . . . . . . . 58 B.9. Control Fields . . . . . . . . . . . . . . . . . . . . . . 59
B.10. Use Of "ENFORCE" Statements As Conditionals . . . . . . . 60 B.10. Use Of "ENFORCE" Statements As Conditionals . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63
Intellectual Property and Copyright Statements . . . . . . . . . . 64 Intellectual Property and Copyright Statements . . . . . . . . . . 65
1. Introduction 1. Introduction
ROHC-FN is a formal notation designed to help with the definition of ROHC-FN is a formal notation designed to help with the definition of
ROHC [I-D.ietf-rohc-rfc3095bis-framework] header compression ROHC [I-D.ietf-rohc-rfc3095bis-framework] header compression
profiles. Previous header compression profiles have been so far profiles. Previous header compression profiles have been so far
specified using a combination of English text together with ASCII Box specified using a combination of English text together with ASCII Box
notation. Unfortunately, this was sometimes unclear and ambiguous, notation. Unfortunately, this was sometimes unclear and ambiguous,
revealing the limitations of defining complex structures and revealing the limitations of defining complex structures and
encodings for compressed formats this way. The primary objective of encodings for compressed formats this way. The primary objective of
skipping to change at page 23, line 8 skipping to change at page 23, line 8
be used to improve readability. Their use is optional. be used to improve readability. Their use is optional.
Comments may help to provide clarifications to the reader, and serve Comments may help to provide clarifications to the reader, and serve
different purposes to implementers. Comments should thus not be different purposes to implementers. Comments should thus not be
considered of lesser importance when inserting them into a ROHC-FN considered of lesser importance when inserting them into a ROHC-FN
specification; they should be consistent with the normative part of specification; they should be consistent with the normative part of
the specification. the specification.
4.9. "ENFORCE" Statements 4.9. "ENFORCE" Statements
An "ENFORCE" statement shares some similarities with an encoding The "ENFORCE" statement provides a way to add predicates to a format,
method. Specifically, whereas an encoding method binds several field all of which must be fulfilled for the format to succeed. An
"ENFORCE" statement shares some similarities with an encoding method.
Specifically, whereas an encoding method binds several field
attributes at once, an "ENFORCE" statement typically binds just one attributes at once, an "ENFORCE" statement typically binds just one
of them. In fact, all the bindings that encoding methods create can of them. In fact, all the bindings that encoding methods create can
be expressed in terms of a collection of "ENFORCE" statements. Here be expressed in terms of a collection of "ENFORCE" statements. Here
is an example "ENFORCE" statement which binds the "UVALUE" attribute is an example "ENFORCE" statement which binds the "UVALUE" attribute
of a field to 5. of a field to 5.
ENFORCE(field.UVALUE == 5); ENFORCE(field.UVALUE == 5);
An "ENFORCE" statement must only be used inside a field list (see An "ENFORCE" statement must only be used inside a field list (see
Section 4.12). It attempts to force the expression given to be true Section 4.12). It attempts to force the expression given to be true
skipping to change at page 30, line 22 skipping to change at page 30, line 38
pattern. Therefore a CRC polynomial with n terms in it is pattern. Therefore a CRC polynomial with n terms in it is
represented by a bit pattern with n-1 bits set. represented by a bit pattern with n-1 bits set.
The CRC is calculated in least significant bit (LSB) order. The CRC is calculated in least significant bit (LSB) order.
For example: For example:
// 3 bit CRC, C(x) = x^0 + x^1 + x^3 // 3 bit CRC, C(x) = x^0 + x^1 + x^3
crc_field =:= crc(3, 0x6, 0xF, THIS.CVALUE, THIS.CLENGTH); crc_field =:= crc(3, 0x6, 0xF, THIS.CVALUE, THIS.CLENGTH);
Usage of the "THIS" keyword (see Section 4.6) as shown in the example Usage of the "THIS" keyword (see Section 4.6) as shown above, is
above, is typical when using "crc" encoding. It causes the CRC to be typical when using "crc" encoding. For example, when used in the
encoding method for an entire header, it causes the CRC to be
calculated over all fields in the header. calculated over all fields in the header.
4.12. Definition of Encoding Methods 4.12. Definition of Encoding Methods
New encoding methods can be defined in a formal specification. These New encoding methods can be defined in a formal specification. These
compose groups of individual fields into a contiguous block. compose groups of individual fields into a contiguous block.
Encoding methods have names and may have parameters; they can also be Encoding methods have names and may have parameters; they can also be
used in the same way as any other encoding method from the library of used in the same way as any other encoding method from the library of
encoding methods. Since they can contain references to other encoding methods. Since they can contain references to other
skipping to change at page 42, line 43 skipping to change at page 43, line 35
Thanks to Stewart Sadler, Caroline Daniels, Alan Finney and David Thanks to Stewart Sadler, Caroline Daniels, Alan Finney and David
Findlay for their reviews and comments. Thanks to Rob Hancock and Findlay for their reviews and comments. Thanks to Rob Hancock and
Stephen McCann for early work on the formal notation. The authors Stephen McCann for early work on the formal notation. The authors
would also like to thank Christian Schmidt, Qian Zhang, Hongbin Liao would also like to thank Christian Schmidt, Qian Zhang, Hongbin Liao
and Max Riegel for their comments and valuable input. and Max Riegel for their comments and valuable input.
Additional thanks: this document was reviewed during working group Additional thanks: this document was reviewed during working group
last-call by committed reviewers Mark West, Carsten Bormann and Joe last-call by committed reviewers Mark West, Carsten Bormann and Joe
Touch, as well as by Sally Floyd who provided a review at the request Touch, as well as by Sally Floyd who provided a review at the request
of the Transport Area Directors. of the Transport Area Directors. Thanks also to Magnus Westerlund
for his feedback in preparation for the IESG review.
9. References 9. References
9.1. Normative References 9.1. Normative References
[C90] ISO/IEC, "ISO/IEC 9899:1990 Information technology -- [C90] ISO/IEC, "ISO/IEC 9899:1990 Information technology --
Programming Language C", ISO 9899:1990, April 1990. Programming Language C", ISO 9899:1990, April 1990.
[I-D.ietf-rohc-rfc3095bis-framework] [I-D.ietf-rohc-rfc3095bis-framework]
Jonsson, L., "The RObust Header Compression (ROHC) Jonsson, L., "The RObust Header Compression (ROHC)
Framework", draft-ietf-rohc-rfc3095bis-framework-01 (work Framework", draft-ietf-rohc-rfc3095bis-framework-01 (work
in progress), July 2006. in progress), July 2006.
skipping to change at page 50, line 10 skipping to change at page 51, line 10
Firstly, and most importantly, the "flow_id" field is notated as Firstly, and most importantly, the "flow_id" field is notated as
"static" which means that it doesn't change from packet to packet. "static" which means that it doesn't change from packet to packet.
However, the notation does not indicate how to communicate the value However, the notation does not indicate how to communicate the value
of the field initially. There is no point saying "it's the same of the field initially. There is no point saying "it's the same
value as last time", if there has not been a first time where we value as last time", if there has not been a first time where we
define what that value is, so that it can be referred back to. The define what that value is, so that it can be referred back to. The
above notation provides no way of communicating that. Similarly with above notation provides no way of communicating that. Similarly with
the sequence number -- there needs to be a way of communicating its the sequence number -- there needs to be a way of communicating its
initial value. In fact, except for the explicit notation indicating initial value. In fact, except for the explicit notation indicating
their lengths, even the lengths of these two fields would be left their lengths, even the lengths of these two fields would be left
undefined. undefined. This problem will be solved below, in Appendix B.5.
Secondly, the sequence number field is communicated very efficiently Secondly, the sequence number field is communicated very efficiently
in zero bits, but it is not at all robust against packet loss. If a in zero bits, but it is not at all robust against packet loss. If a
packet is lost then there is no way to handle the missing sequence packet is lost then there is no way to handle the missing sequence
number. number. When communicating sequence numbers, or any other field
encoding with LSB encoding, a very important consideration for the
notator is how robust against packet loss the compressed protocol
should be. This will vary a lot from protocol stack to protocol
stack. For the example protocol we'll assume short, low overhead
flows and say we need to be robust to the loss of just one packet,
which we can achieve with two bits of LSB encoding (one bit isn't
enough since the sequence number increases by three each time, see
Section 4.11.5). This will be solved below in Appendix B.5.
Finally, although the flag bits are usually the same as in the Finally, although the flag bits are usually the same as in the
previous header in the flow, the profile doesn't make any use of this previous header in the flow, the profile doesn't make any use of this
fact; since they are sometimes not the same as those in the previous fact; since they are sometimes not the same as those in the previous
header, it is not safe to say that they are always the same, so header, it is not safe to say that they are always the same, so
"static" encoding can't be used exclusively. We solve all three of "static" encoding can't be used exclusively. This problem will be
these problems below: robustness first since it is simplest, and the solved later through the use of multiple formats in Appendix B.6.
remainder in the next two sections.
When communicating sequence numbers, or any other field encoding with
LSB encoding, a very important consideration for the notator is how
robust against packet loss the compressed protocol should be. This
will vary a lot from protocol stack to protocol stack. For the
example protocol we'll assume short, low overhead flows and say we
need to be robust to the loss of just one packet, which we can
achieve with two bits of LSB encoding (one bit isn't enough since the
sequence number increases by three each time -- see Section 4.11.5 ).
B.5. Specifying Initial Values B.5. Specifying Initial Values
To communicate initial values for fields compressed with a context To communicate initial values for fields compressed with a context
dependent encoding such as "static" or "lsb" we use an "INITIAL" dependent encoding such as "static" or "lsb" we use an "INITIAL"
field list. This can help with fields whose start value is fixed and field list. This can help with fields whose start value is fixed and
known. For example if we knew that at the start of the flow, known. For example if we knew that at the start of the flow,
"flow_id" would always be 1 and "sequence_no" would always be 0, we "flow_id" would always be 1 and "sequence_no" would always be 0, we
could notate that like this: could notate that like this:
skipping to change at page 51, line 27 skipping to change at page 52, line 27
INITIAL { INITIAL {
// set initial values of fields before flow starts // set initial values of fields before flow starts
flow_id =:= uncompressed_value(4, 1); flow_id =:= uncompressed_value(4, 1);
sequence_no =:= uncompressed_value(4, 0); sequence_no =:= uncompressed_value(4, 0);
} }
COMPRESSED obvious { COMPRESSED obvious {
version_no =:= uncompressed_value(2, 1); version_no =:= uncompressed_value(2, 1);
type =:= irregular(2); type =:= irregular(2);
flow_id =:= static; flow_id =:= static;
sequence_no =:= lsb(0, -3); sequence_no =:= lsb(2, -3);
abc_flag_bits =:= irregular(3); abc_flag_bits =:= irregular(3);
reserved_flag =:= uncompressed_value(1, 0); reserved_flag =:= uncompressed_value(1, 0);
} }
} }
However, this use of "INITIAL" is no good since the initial values of However, this use of "INITIAL" is no good since the initial values of
both "flow_id" and "sequence_no" vary from flow to flow. "INITIAL" both "flow_id" and "sequence_no" vary from flow to flow. "INITIAL"
is only applicable where the initial value of a field is fixed, as is is only applicable where the initial value of a field is fixed, as is
often the case with control fields. often the case with control fields.
skipping to change at page 64, line 7 skipping to change at page 65, line 7
Ericsson Ericsson
Box 920 Box 920
Lulea SE-971 28 Lulea SE-971 28
Sweden Sweden
Phone: +46 (0) 8 404 29 43 Phone: +46 (0) 8 404 29 43
Email: ghyslain.pelletier@ericsson.com Email: ghyslain.pelletier@ericsson.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 21 change blocks. 
50 lines changed or deleted 53 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/