--- /tmp/08 Mon Feb 26 16:17:27 2001 +++ /tmp/09 Mon Feb 26 16:17:16 2001 @@ -21,9 +21,10 @@ Takeshi Yoshimura, NTT DoCoMo Haihong Zheng, Nokia - February 7, 2001 - RObust Header Compression (ROHC) - + February 26, 2001 + RObust Header Compression (ROHC): + Framework and four profiles: RTP, UDP, ESP, and uncompressed + @@ -72,8 +73,9 @@ Revision history (remove before publishing) + -09: Incorporate minor editorial comments from IETF last-call -08: Incorporate changes from second, abbreviated WG last call; - ready for submission to an IESG last-call. + ready for submission to an IETF last-call. -07: Incorporate changes from WG last call -06: Final changes for WG last call -05: Editorial changes @@ -100,8 +102,8 @@ 3.3. Requirements on a new header compression scheme..............16 3.4. Classification of header fields..............................16 4. Header compression framework...................................18 - 4.1. Operating assumptions........................................18 + 4.1. Operating assumptions........................................18 4.2. Dynamicity...................................................19 4.3. Compression and decompression states.........................20 4.3.1. Compressor states..........................................21 @@ -138,22 +140,22 @@ 5.2.5.2. Segmentation protocol....................................47 5.2.6. ROHC initial decompressor processing.......................49 5.2.7. ROHC RTP packet formats from compressor to decompressor....50 - 5.2.8. Parameters needed for mode transition in ROHC RTP..........51 + 5.2.8. Parameters needed for mode transition in ROHC RTP..........52 5.3. Operation in Unidirectional mode.............................52 5.3.1. Compressor states and logic (U-mode).......................52 5.3.1.1. State transition logic (U-mode)..........................52 - 5.3.1.1.1. Optimistic approach, upwards transition................52 + 5.3.1.1.1. Optimistic approach, upwards transition................53 5.3.1.1.2. Timeouts, downward transition..........................53 5.3.1.1.3. Need for updates, downward transition..................53 5.3.1.2. Compression logic and packets used (U-mode)..............53 - 5.3.1.3. Feedback in Unidirectional mode..........................53 + 5.3.1.3. Feedback in Unidirectional mode..........................54 5.3.2. Decompressor states and logic (U-mode).....................54 5.3.2.1. State transition logic (U-mode)..........................54 5.3.2.2. Decompression logic (U-mode).............................54 - 5.3.2.2.1. Decide whether decompression is allowed................54 + 5.3.2.2.1. Decide whether decompression is allowed................55 5.3.2.2.2. Reconstruct and verify the header......................55 - 5.3.2.2.3. Actions upon CRC failure...............................55 + 5.3.2.2.3. Actions upon CRC failure...............................55 5.3.2.2.4. Correction of SN LSB wraparound........................57 5.3.2.2.5. Repair of incorrect SN updates.........................58 5.3.2.3. Feedback in Unidirectional mode..........................59 @@ -168,17 +170,17 @@ 5.4.2.2. Feedback logic (O-mode)..................................61 5.5. Operation in Bidirectional Reliable mode.....................62 5.5.1. Compressor states and logic (R-mode).......................62 - 5.5.1.1. State transition logic (R-mode)..........................62 + 5.5.1.1. State transition logic (R-mode)..........................63 5.5.1.1.1. Upwards transition.....................................63 5.5.1.1.2. Downward transition....................................63 5.5.1.2. Compression logic and packets used (R-mode)..............63 5.5.2. Decompressor states and logic (R-mode).....................65 5.5.2.1. Decompression logic (R-mode).............................65 5.5.2.2. Feedback logic (R-mode)..................................65 - 5.6. Mode transitions.............................................66 + 5.6. Mode transitions.............................................67 5.6.1. Compression and decompression during mode transitions......67 5.6.2. Transition from Unidirectional to Optimistic mode..........68 - 5.6.3. From Optimistic to Reliable mode...........................68 + 5.6.3. From Optimistic to Reliable mode...........................69 5.6.4. From Unidirectional to Reliable mode.......................69 5.6.5. From Reliable to Optimistic mode...........................69 5.6.6. Transition to Unidirectional mode..........................70 @@ -204,8 +206,8 @@ 5.7.6.11. RTP feedback example....................................89 5.7.7. RTP IR and IR-DYN packets..................................90 5.7.7.1. Basic structure of the IR packet.........................90 - 5.7.7.2. Basic structure of the IR-DYN packet.....................91 + 5.7.7.2. Basic structure of the IR-DYN packet.....................91 5.7.7.3. Initialization of IPv6 Header [IPv6].....................93 5.7.7.4. Initialization of IPv4 Header [IPv4, section 3.1]........94 5.7.7.5. Initialization of UDP Header [RFC-768]...................95 @@ -256,8 +258,8 @@ 6.2. RTCP........................................................127 6.3. Implementation parameters and signals.......................128 6.3.1. ROHC implementation parameters at compressor..............128 - 6.3.2. ROHC implementation parameters at decompressor............130 + 6.3.2. ROHC implementation parameters at decompressor............130 6.4. Handling of resource limitations at the decompressor........130 6.5. Implementation structures...................................131 6.5.1. Compressor context........................................131 @@ -280,14 +282,14 @@ A.1.5. Summary for IP/UDP/RTP....................................146 A.2. Analysis of change patterns of header fields................146 A.2.1. IPv4 Identification.......................................148 - A.2.2. IP Traffic-Class / Type-Of-Service........................149 + A.2.2. IP Traffic-Class / Type-Of-Service........................150 A.2.3. IP Hop-Limit / Time-To-Live...............................150 A.2.4. UDP Checksum..............................................150 A.2.5. RTP CSRC Counter..........................................150 A.2.6. RTP Marker................................................150 A.2.7. RTP Payload Type..........................................150 A.2.8. RTP Sequence Number.......................................150 - A.2.9. RTP Timestamp.............................................150 + A.2.9. RTP Timestamp.............................................151 A.2.10. RTP Contributing Sources (CSRC)..........................151 A.3. Header compression strategies...............................151 A.3.1. Do not send at all........................................151 @@ -652,7 +654,7 @@ Relevant information from past packets is maintained in a context. The context information is used to compress (decompress) subsequent - packets. The compressor and decompressor updates their contexts upon + packets. The compressor and decompressor update their contexts upon certain events. Impairment events may lead to inconsistencies between the contexts of the compressor and decompressor, which in turn may cause incorrect decompression. A robust header compression scheme @@ -810,14 +812,14 @@ field in the header to be compressed, additional information is sent to update the parameters of that function. - Headers specific to Mobile IP do not receive any special treatment in - this document. They are compressible, however, and it is expected - that the compression efficiency for Mobile IP headers will be good - enough due to the handling of extension header lists and tunneling - headers. It would be relatively painless to introduce a new ROHC - profile with special treatment for Mobile IP specific headers should - the completed work on the Mobile IP protocols (work in progress in - the IETF) make that necessary. + Headers specific to Mobile IP (for IPv4 or IPv6) do not receive any + special treatment in this document. They are compressible, however, + and it is expected that the compression efficiency for Mobile IP + headers will be good enough due to the handling of extension header + lists and tunneling headers. It would be relatively painless to + introduce a new ROHC profile with special treatment for Mobile IPv6 + specific headers should the completed work on the Mobile IPv6 + protocols (work in progress in the IETF) make that necessary. 4. Header compression framework @@ -855,16 +857,16 @@ Reordering - The channel between compressor and decompressor is not assumed to - reorder packets, i.e., the decompressor receives packets in the - same order as the compressor sends them. (Reordering before the - compression point, however, is dealt with, i.e., there is no - assumption that the compressor will only receive packets in + The channel between compressor and decompressor is required to + maintain packet ordering, i.e., the decompressor must receive + packets in the same order as the compressor sent them. (Reordering + before the compression point, however, is dealt with, i.e., there + is no assumption that the compressor will only receive packets in sequence.) Duplication - The channel between compressor and decompressor is not assumed to + The channel between compressor and decompressor is required to not duplicate packets. (Duplication before the compression point, however, is dealt with, i.e., there is no assumption that the compressor will receive only one copy of each packet.) @@ -1004,7 +1006,8 @@ - variations in packet headers - positive feedback from decompressor (Acknowledgments -- ACKs) - negative feedback from decompressor (Negative ACKs -- NACKs) - - periodic timeouts (when no feedback is used) + - periodic timeouts (when operating in unidirectional mode, i.e., + over simplex channels or when feedback is not enabled) How transitions are performed is explained in detail in chapter 5 for each mode of operation. @@ -2100,9 +2103,10 @@ to, and interpreted by, the compressor associated with feedback on that channel. Thus, the feedback information must contain CID information if the associated compressor can use more than one - context. How a compressor is associated with feedback on a - particular channel needs to be defined in a "ROHC over X" - document. + context. The ROHC feedback scheme requires that a channel carries + feedback to at most one compressor. How a compressor is associated + with feedback on a particular channel needs to be defined in a + "ROHC over X" document. C)The ROHC feedback information format is octet-aligned, i.e., starts at an octet boundary, to allow using the format over a @@ -2146,8 +2150,8 @@ The total size of the feedback data field is determinable upon reception by the decompressor, by inspection of the Code field and - possibly the Size field. This explicit length information allows + possibly the Size field. This explicit length information allows piggybacking and also sending more than one feedback element in a packet. @@ -2198,8 +2202,8 @@ +---+---+---+---+---+---+---+---+ Acktype: 0 = ACK - 1 = NACK + 1 = NACK 2 = STATIC-NACK 3 is reserved (MUST NOT be used. Otherwise unparseable.) @@ -2301,8 +2304,8 @@ CRC: 8-bit CRC computed using the polynomial of section 5.9.1. Its coverage is profile-dependent, but it MUST cover at least the - initial part of the packet ending with the Profile field. Any + initial part of the packet ending with the Profile field. Any information which initializes the context of the decompressor should be protected by the CRC. @@ -2443,7 +2446,13 @@ 5) If the first remaining octet starts with 1111111, this is a segment: attempt reconstruction using the segmentation protocol - (5.2.5); this finishes the processing of this packet. + (5.2.5). If a reconstructed packet is not produced, this + finishes the processing of the original packet. If a + reconstructed packet is produced, it is fed into step 1) + above. Padding, segments, and feedback are not allowed in + reconstructed packets, so when processing them, steps 1), + 4), and 5) are modified so that the packet is discarded + without further action when their conditions match. 6) Here, it is known that the rest is forward information (unless the header is damaged). @@ -3373,11 +3374,12 @@ Possible values for the C_TRANS parameter are (P)ENDING and (D)ONE. C_TRANS MUST be initialized to D. When C_TRANS is P, it is REQUIRED - 1) that the compressor only use packet formats common to all modes, - 2) that the compressor not transit to the SO state, - 3) that new mode transition requests be ignored. + 2) that mode information is included in packets sent, + at least periodically, + 3) that the compressor not transit to the SO state, + 4) that new mode transition requests be ignored. Parameters for the decompressor side: @@ -3452,11 +3453,11 @@ As long as the decompressor has not received an UOR-2, IR-DYN, or IR packet with the mode transition parameter set to R, it must stay in - Optimistic mode. The compressor must stay in the FO state until it - has received an ACK for a UOR-2, IR-DYN, or IR packet sent with the - mode transition parameter set to R. When the decompressor receives - packet types 0 or 1, after having ACKed an UOR-2, IR-DYN, or IR - packet, it sets D_TRANS to D. + Optimistic mode. The compressor must not send packet types 1 or 0 + while C_TRANS is P, i.e., not until it has received an ACK for a UOR- + 2, IR-DYN, or IR packet sent with the mode transition parameter set + to R. When the decompressor receives packet types 0 or 1, after + having ACKed an UOR-2, IR-DYN, or IR packet, it sets D_TRANS to D. 5.6.4. From Unidirectional to Reliable mode @@ -3495,11 +3495,11 @@ As long as the decompressor has not received an UOR-2, IR-DYN, or IR packet with the mode transition parameter set to O, it must stay in - Reliable mode. The compressor must stay in the FO state until it has - received an ACK for an UOR-2, IR-DYN, or IR packet sent with the mode - transition parameter set to O. When the decompressor receives packet - types 0 or 1, after having ACKed the UOR-2, IR-DYN, or IR packet, it - sets D_TRANS to D. + Reliable mode. The compressor must not send packet types 0 or 1 while + C_TRANS is P, i.e., not until it has received an ACK for an UOR-2, + IR-DYN, or IR packet sent with the mode transition parameter set to + O. When the decompressor receives packet types 0 or 1, after having + ACKed the UOR-2, IR-DYN, or IR packet, it sets D_TRANS to D. 5.6.6. Transition to Unidirectional mode @@ -5057,8 +5058,8 @@ In U/O-mode, the compressor sends generation identifiers with the Generic lists until - 2) a generation identifier has been repeated L times, or - 3) an acknowledgment for a header carrying a generation identifier + 1) a generation identifier has been repeated L times, or + 2) an acknowledgment for a header carrying a generation identifier has been received. The repeated (1) or acknowledged (2) list can be used as a reference list to compress subsequent lists and is kept together @@ -7085,8 +7085,8 @@ | Packet Length | 16 | INFERRED | | Identification | 16 | CHANGING | | Reserved flag | 1 | STATIC-KNOWN | - | May Fragment flag | 1 | STATIC | - | Last Fragment flag | 1 | STATIC-KNOWN | + | Don't Fragment flag | 1 | STATIC | + | More Fragments flag | 1 | STATIC-KNOWN | | Fragment Offset | 13 | STATIC-KNOWN | | Time To Live | 8 | CHANGING | | Protocol | 8 | STATIC | @@ -7121,11 +7121,12 @@ Flags The Reserved flag must be set to zero and is therefore classified - as STATIC-KNOWN. The May Fragment flag will be constant for all - packets in a stream and is therefore classified as STATIC. Finally, - the Last Fragment bit is expected to be zero because fragmentation - is NOT expected, due to the small packet size expected. The Last - Fragment bit is therefore classified as STATIC-KNOWN. + as STATIC-KNOWN. The Don't Fragment (DF) flag will be constant for + all packets in a stream and is therefore classified as STATIC. + Finally, the More Fragments (MF) flag is expected to be zero + because fragmentation is NOT expected, due to the small packet size + expected. The More Fragments flag is therefore classified as + STATIC-KNOWN. Fragment Offset @@ -7392,32 +7393,16 @@ alive in the network. This means that assignment of IP ID values can be done in various ways, which we have separated into three classes. - Sequential - - This assignment policy keeps a separate counter for each outgoing - packet stream and thus the IP ID value will increment by one for - each packet in the stream. Therefore, the delta value of the - field is constant and well known a priori. When RTP is used on - top of UDP and IP, the IP ID value follows the RTP Sequence - Number. This assignment policy is the most desirable for header - compression purposes but its usage is not as common as it should - be. The reason is that it can be realized only if UDP and IP are - implemented together so that UDP, which separates packet streams - by the Port identification fields, can make IP use separate ID - counters for each packet stream. - Sequential jump - This is the most common assignment policy in today's IP stacks. - The difference from the sequential method is that only one - counter is used for all connections. When the sender is running - - more than one packet stream simultaneously, the IP ID can - increase by more than one. The IP ID values will be much more - predictable and require less bits to transfer than random values, - and the packet-to-packet increment (determined by the number of - active outgoing packet streams and sending frequencies) will - usually be limited. + This is the most common assignment policy in today's IP stacks. A + single IP ID counter is used for all packet streams. When the + sender is running more than one packet stream simultaneously, the + IP ID can increase by more than one between packets in a stream. + The IP ID values will be much more predictable and require less + bits to transfer than random values, and the packet-to-packet + increment (determined by the number of active outgoing packet + streams and sending frequencies) will usually be limited. Random @@ -7430,6 +7416,31 @@ stacks in cellular terminals SHOULD NOT use this IP ID assignment policy. + Sequential + + This assignment policy keeps a separate counter for each outgoing + packet stream and thus the IP ID value will increment by one for + each packet in the stream, except at wrap around. Therefore, the + delta value of the field is constant and well known a priori. + When RTP is used on top of UDP and IP, the IP ID value follows + the RTP Sequence Number. This assignment policy is the most + desirable for header compression purposes. However, its usage is + not as common as it perhaps should be. The reason may be that it + can be realized only when UDP and IP are implemented together so + that UDP, which separates packet streams by the Port + identification fields, can make IP use separate ID counters for + each packet stream. + + In order to avoid violating [IPv4], packets sharing the same IP + address pair and IP protocol number cannot use the same IP ID + values. Therefore, implementations of sequential policies must + make the ID number spaces disjoint for packet streams of the same + IP protocol going between the same pair of nodes. This can be + done in a number of ways, all of which introduce occasional + jumps, and thus makes the policy less than perfectly sequential. + For header compression purposes less frequent jumps are + preferred. + It should be noted that the ID is an IPv4 mechanism and is therefore not a problem for IPv6. For IPv4 the ID could be handled in three different ways. First, we have the inefficient but reliable solution @@ -7444,16 +7455,11 @@ between the two solutions above. Finally, even for IPv4, header compression could be designed without any additional information for the ID field included in compressed headers. To use such schemes, it - must be known that the sender makes use of the pure sequential - assignment policy for the ID field. That might not be possible to - know, which implies that the applicability of such solutions is very - uncertain. However, designers of IPv4 stacks for cellular terminals - SHOULD use the sequential policy. - - - - - + must be known which assignment policy for the ID field is being used + by the sender. That might not be possible to know, which implies that + the applicability of such solutions is very uncertain. However, + designers of IPv4 stacks for cellular terminals SHOULD use an + assignment policy close to sequential. A.2.2. IP Traffic-Class / Type-Of-Service @@ -7691,7 +7699,7 @@ - This Internet-Draft expires August 07, 2001. + This Internet-Draft expires August 25, 2001.