333:
also sending dynamic packet field differences in FO state. Thus, FO state is essentially static and pseudo-dynamic compression. In Second-Order (SO) state, the compressor is suppressing all dynamic fields such as RTP sequence numbers, and sending only a logical sequence number and partial checksum to cause the other side to predictively generate and verify the headers of the next expected packet. In general, FO state compresses all static fields and most dynamic fields. SO state is compressing all dynamic fields predictively using a sequence number and checksum.
22:
273:
In the
Unidirectional mode of operation, packets are only sent in one direction: from compressor to decompressor. This mode therefore makes ROHC usable over links where a return path from decompressor to compressor is unavailable or undesirable. In order to handle potential decompression errors, the
282:
The
Bidirectional Optimistic mode is similar to the Unidirectional mode, except that a feedback channel is used to send error recovery requests and (optionally) acknowledgments of significant context updates from the decompressor to compressor. The O-mode aims to maximize compression efficiency and
215:
For better performance, the packets are classified into streams before being compressed. This classification takes advantage of inter-packet redundancy. The classification algorithm is not defined by the ROHC protocol itself but left to the equipment vendor's implementation. Once a stream of packets
291:
The
Bidirectional Reliable mode differs in many ways from the previous two modes. The most important differences are a more intensive usage of the feedback channel, and a stricter logic at both the compressor and the decompressor that prevents loss of context synchronization between compressor and
332:
In
Initialization and Refresh (IR) state, the compressor has just been created or reset, and full packet headers are sent. In First-Order (FO) state, the compressor has detected and stored the static fields (such as IP addresses and port numbers) on both sides of the connection. The compressor is
300:
The notion of compressor/decompressor states is orthogonal to the operational modes. Whatever the mode is, both the compressor and the decompressor work in one of their three states. They are basically finite state machines. Every incoming packet may cause the compressor/decompressor to change its
410:
The size of the sequence number (SN) field governs the number of packets that ROHC can lose before the compressor must be reset to continue. The W-LSB algorithm is used to compress the SN in a robust way. The size of the sequence number in 1 and 2 byte ROHC packets is either 4 bits ( −1/+14 frame
304:
The ROHC algorithm is similar to video compression, in that a base frame and then several difference frames are sent to represent an IP packet flow. This has the advantage of allowing ROHC to survive many packet losses in its highest compression state, as long as the base frames are not lost.
180:
ROHC compresses these 40 bytes or 60 bytes of overhead typically into only one or three bytes, by placing a compressor before the link that has limited capacity, and a decompressor after that link. The compressor converts the large overhead to only a few bytes, while the decompressor does the
264:
Both the compressor and the decompressor start in U-mode. They may then transition to O-mode if a usable return link is available, and the decompressor sends a positive acknowledgement, with O-mode specified, to the compressor. The transition to R-mode is achieved in the same way.
360:
A typical ROHC implementation will aim to get the terminal into Second-Order state, where a 1-byte ROHC header can be substituted for the 40-byte IPv4/UDP/RTP or the 60-byte IPv6/UDP/RTP (i.e. VoIP) header. In this state, the 8-bit ROHC header contains three fields:
216:
is classified, it is compressed according to the compression profile that fits best. A compression profile defines the way to compress the different fields in the network headers. Several compression profiles are available, including the following:
582:- "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite". Second version of the profiles found in RFC 3095, RFC 3843 and RFC 4019. It supersedes their definition, but does not obsolete them.
211:
Redundant information is transmitted in the first packets only. The next packets contain variable information, e.g. identifiers or sequence numbers. These fields are transmitted in a compressed form to save more bits.
462:
to address the confusion some have encountered when attempting to interpret and implement ROHC. The first document defines a ROHC framework, while the second defines newer versions of the established ROHC profiles.
423:
defines a generic compression mechanism. It may be extended by defining new compression profiles dedicated to specific protocol headers. New RFCs were published to compress new protocols:
173:, this corresponds to around 60% of the total amount of data sent. Such large overheads may be tolerable in local wired links where capacity is often not an issue, but are excessive for
86:
39:
58:
65:
411:
offset ), or 6 bits ( −1/+62 frame offset ), respectively, so ROHC can tolerate at most 62 lost frames with a 1-2 byte header.
499:
72:
54:
477:
105:
43:
142:
192:, by the fact that it performs well over links where the packet loss rate is high, such as wireless links.
138:
624:
79:
619:
32:
130:
568:- "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)" (obsoleted by RFC 6846)
200:
The ROHC protocol takes advantage of information redundancy in the headers of the following:
596:- "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)" (obsoletes RFC 4996)
184:
The ROHC compression scheme differs from other compression schemes, such as IETF RFC
8:
174:
126:
503:
301:
internal state. Every state refers to a defined behaviour and compression level.
250:
According to RFC 3095, the ROHC scheme has three modes of operation, as follows:
593:
586:
579:
572:
565:
558:
551:
547:
540:
533:
459:
455:
442:
435:
428:
420:
368:
a 4-bit sequence number (with a range of −1 ... +14 packets from the base frame)
207:
several network packets that belong to one single stream (e.g. the IP addresses)
189:
185:
527:
274:
compressor sends periodic refreshes of the stream context to the decompressor.
613:
561:- "The RObust Header Compression (ROHC) Framework" (obsoleted by RFC 5795)
438:
defines a compression profile for UDP-Lite/IP and RTP/UDP-Lite/IP headers.
204:
one single network packet (e.g. the payload lengths in IP and UDP headers)
589:- "The RObust Header Compression (ROHC) Framework" (obsoletes RFC 4995)
536:- "ROHC Framework and four profiles: RTP, UDP, ESP, and uncompressed"
380:
The decompressor's state machine defines the following three states:
21:
313:
The compressor's state machine defines the following three states:
146:
134:
394:
Transitions between the above states occur when the decompressor:
365:
a 1-bit packet-type flag (set to '1' only for longer ROHC headers)
157:
In streaming applications, the overhead of IP, UDP, and RTP is 40
472:
341:
Transitions between the above states occur when the compressor:
327:
599:
355:
292:
decompressor, except for very high residual bit error rates.
158:
605:
A free and efficient library implementing the ROHC standard
431:
defines a compression profile for IP headers or IP tunnels.
348:
receives a positive/negative feedback from the decompressor
170:
166:
162:
497:
277:
336:
604:
286:
345:
compresses a packet that contains too many variations
195:
46:. Unsourced material may be challenged and removed.
414:
152:
543:- "ROHC Terminology and Channel Mapping Examples"
445:defines a compression profile for TCP/IP headers.
295:
611:
600:A free implementation of ROHC on sourceforge.net
454:There have been two new RFCs published RFC
177:and wireless systems where bandwidth is scarce.
528:Official charter of the ROHC IETF working group
283:aims for sparse usage of the feedback channel.
268:
550:- "Corrections and Clarifications to RFC
328:Operations in the different compressor states
125:) is a standardized method to compress the
356:Second-Order ROHC headers – 1-byte headers
257:the Bidirectional Optimistic mode (O-mode)
106:Learn how and when to remove this message
260:the Bidirectional Reliable mode (R-mode)
612:
375:
278:Bidirectional Optimistic Mode (O-Mode)
337:Transitions between compressor states
317:Initialization and Refresh (IR) state
245:
308:
287:Bidirectional Reliable Mode (R-Mode)
44:adding citations to reliable sources
15:
401:fails to decompress several packets
13:
449:
398:successfully decompresses a packet
351:periodically refreshes the context
14:
636:
521:
478:Static Context Header Compression
498:Michael Dosch and Steve Church.
254:the Unidirectional mode (U-mode)
196:Main ROHC compression principles
20:
415:Additional compression profiles
153:The need for header compression
31:needs additional citations for
500:"VoIP In The Broadcast Studio"
491:
296:Compressor/decompressor states
1:
484:
405:
575:- "Formal Notation for ROHC"
502:. Axia Audio. Archived from
269:Unidirectional Mode (U-Mode)
7:
466:
55:"Robust Header Compression"
10:
641:
119:Robust Header Compression
323:Second Order (SO) state
320:First Order (FO) state
387:Static Context State
40:improve this article
376:Decompressor states
625:Internet Standards
390:Full Context State
246:Modes of operation
175:wide area networks
165:, or 60 bytes for
309:Compressor states
116:
115:
108:
90:
632:
620:Data compression
515:
514:
512:
511:
495:
384:No Context State
111:
104:
100:
97:
91:
89:
48:
24:
16:
640:
639:
635:
634:
633:
631:
630:
629:
610:
609:
524:
519:
518:
509:
507:
496:
492:
487:
469:
452:
450:Newer ROHC RFCs
417:
408:
378:
358:
339:
330:
311:
298:
289:
280:
271:
248:
238:RTP/UDP-Lite/IP
198:
155:
112:
101:
95:
92:
49:
47:
37:
25:
12:
11:
5:
638:
628:
627:
622:
608:
607:
602:
597:
590:
583:
576:
569:
562:
555:
544:
537:
530:
523:
522:External links
520:
517:
516:
489:
488:
486:
483:
482:
481:
475:
468:
465:
451:
448:
447:
446:
439:
432:
416:
413:
407:
404:
403:
402:
399:
392:
391:
388:
385:
377:
374:
373:
372:
369:
366:
357:
354:
353:
352:
349:
346:
338:
335:
329:
326:
325:
324:
321:
318:
310:
307:
297:
294:
288:
285:
279:
276:
270:
267:
262:
261:
258:
255:
247:
244:
243:
242:
239:
236:
233:
230:
227:
224:
221:
209:
208:
205:
197:
194:
154:
151:
114:
113:
28:
26:
19:
9:
6:
4:
3:
2:
637:
626:
623:
621:
618:
617:
615:
606:
603:
601:
598:
595:
591:
588:
584:
581:
577:
574:
570:
567:
563:
560:
556:
553:
549:
545:
542:
538:
535:
531:
529:
526:
525:
506:on 2011-10-07
505:
501:
494:
490:
479:
476:
474:
471:
470:
464:
461:
458:and RFC
457:
444:
441:The RFC
440:
437:
434:The RFC
433:
430:
427:The RFC
426:
425:
424:
422:
419:The RFC
412:
400:
397:
396:
395:
389:
386:
383:
382:
381:
370:
367:
364:
363:
362:
350:
347:
344:
343:
342:
334:
322:
319:
316:
315:
314:
306:
302:
293:
284:
275:
266:
259:
256:
253:
252:
251:
240:
237:
234:
231:
228:
225:
222:
219:
218:
217:
213:
206:
203:
202:
201:
193:
191:
188:and RFC
187:
182:
178:
176:
172:
168:
164:
160:
150:
148:
144:
140:
136:
132:
128:
124:
120:
110:
107:
99:
88:
85:
81:
78:
74:
71:
67:
64:
60:
57: –
56:
52:
51:Find sources:
45:
41:
35:
34:
29:This article
27:
23:
18:
17:
508:. Retrieved
504:the original
493:
453:
418:
409:
393:
379:
359:
340:
331:
312:
303:
299:
290:
281:
272:
263:
249:
220:Uncompressed
214:
210:
199:
183:
179:
156:
122:
118:
117:
102:
96:October 2015
93:
83:
76:
69:
62:
50:
38:Please help
33:verification
30:
371:a 3-bit CRC
229:UDP-Lite/IP
145:headers of
614:Categories
510:2011-06-21
485:References
406:Robustness
235:RTP/UDP/IP
181:opposite.
66:newspapers
592:RFC
585:RFC
578:RFC
571:RFC
564:RFC
557:RFC
546:RFC
539:RFC
532:RFC
149:packets.
467:See also
147:Internet
135:UDP-Lite
473:6LoWPAN
223:IP-only
80:scholar
480:(SCHC)
241:TCP/IP
232:ESP/IP
226:UDP/IP
169:. For
141:, and
82:
75:
68:
61:
53:
159:bytes
87:JSTOR
73:books
594:6846
587:5795
580:5225
573:4997
566:4996
559:4995
552:3095
548:4815
541:3759
534:3095
460:5225
456:4995
443:6846
436:4019
429:3843
421:3095
190:2508
186:1144
171:VoIP
167:IPv6
163:IPv4
161:for
123:ROHC
59:news
143:TCP
139:RTP
131:UDP
42:by
616::
137:,
133:,
129:,
127:IP
554:"
513:.
121:(
109:)
103:(
98:)
94:(
84:·
77:·
70:·
63:·
36:.
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.
