1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
|
<pre>Network Working Group G. Pelletier
Request for Comments: 4019 Ericsson AB
Category: Standards Track April 2005
<span class="h1">RObust Header Compression (ROHC):</span>
<span class="h1">Profiles for User Datagram Protocol (UDP) Lite</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines Robust Header Compression (ROHC) profiles for
compression of Real-Time Transport Protocol, User Datagram Protocol-
Lite, and Internet Protocol (RTP/UDP-Lite/IP) packets and UDP-
Lite/IP. These profiles are defined based on their differences with
the profiles for UDP as specified in <a href="./rfc3095">RFC 3095</a>.
Table of Contents
<a href="#section-1">1</a>. Introduction.................................................. <a href="#page-2">2</a>
<a href="#section-2">2</a>. Terminology................................................... <a href="#page-3">3</a>
<a href="#section-3">3</a>. Background.................................................... <a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. Overview of the UDP-Lite Protocol....................... <a href="#page-3">3</a>
<a href="#section-3.2">3.2</a>. Expected Behaviours of UDP-Lite Flows................... <a href="#page-5">5</a>
<a href="#section-3.2.1">3.2.1</a>. Per-Packet Behavior............................. <a href="#page-5">5</a>
<a href="#section-3.2.2">3.2.2</a>. Inter-Packet Behavior........................... <a href="#page-5">5</a>
<a href="#section-3.2.3">3.2.3</a>. Per-Flow Behavior............................... <a href="#page-5">5</a>
<a href="#section-3.3">3.3</a>. Header Field Classification............................. <a href="#page-5">5</a>
<a href="#section-4">4</a>. Rationale behind the Design of ROHC Profiles for UDP-Lite..... <a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. Design Motivations...................................... <a href="#page-6">6</a>
<a href="#section-4.2">4.2</a>. ROHC Considerations..................................... <a href="#page-6">6</a>
<a href="#section-5">5</a>. ROHC Profiles for UDP-Lite.................................... <a href="#page-6">6</a>
<a href="#section-5.1">5.1</a>. Context Parameters...................................... <a href="#page-7">7</a>
<a href="#section-5.2">5.2</a>. Initialization.......................................... <a href="#page-8">8</a>
<a href="#section-5.2.1">5.2.1</a>. Initialization of the UDP-Lite Header [<a href="#ref-1" title=""Key words for use in RFCs to Indicate Requirement Levels"">1</a>]....... <a href="#page-8">8</a>
<a href="#section-5.2.2">5.2.2</a>. Compressor and Decompressor Logic............... <a href="#page-9">9</a>
<span class="grey">Pelletier Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4019">RFC 4019</a> ROHC: Profiles for UDP-Lite April 2005</span>
<a href="#section-5.3">5.3</a>. Packet Formats.......................................... <a href="#page-9">9</a>
<a href="#section-5.3.1">5.3.1</a>. General Packet Format........................... <a href="#page-9">9</a>
<a href="#section-5.3.2">5.3.2</a>. Packet Type CCE: CCE(), CCE(ON), and CCE(OFF)... <a href="#page-10">10</a>
<a href="#section-5.3.2.1">5.3.2.1</a>. Properties of CCE():.................. <a href="#page-11">11</a>
<a href="#section-5.3.2.2">5.3.2.2</a>. Properties of CCE(ON):................ <a href="#page-11">11</a>
<a href="#section-5.3.2.3">5.3.2.3</a>. Properties of CCE(OFF):............... <a href="#page-12">12</a>
<a href="#section-5.4">5.4</a>. Compressor Logic........................................ <a href="#page-12">12</a>
<a href="#section-5.5">5.5</a>. Decompressor Logic...................................... <a href="#page-12">12</a>
<a href="#section-5.6">5.6</a>. Additional Mode Transition Logic........................ <a href="#page-13">13</a>
<a href="#section-5.7">5.7</a>. The CONTEXT_MEMORY Feedback Option...................... <a href="#page-13">13</a>
<a href="#section-5.8">5.8</a>. Constant IP-ID.......................................... <a href="#page-13">13</a>
<a href="#section-6">6</a>. Security Considerations....................................... <a href="#page-14">14</a>
<a href="#section-7">7</a>. IANA Considerations........................................... <a href="#page-14">14</a>
<a href="#section-8">8</a>. Acknowledgments............................................... <a href="#page-15">15</a>
<a href="#section-9">9</a>. References.................................................... <a href="#page-15">15</a>
<a href="#section-9.1">9.1</a>. Normative References.................................... <a href="#page-15">15</a>
<a href="#section-9.2">9.2</a>. Informative References.................................. <a href="#page-15">15</a>
<a href="#appendix-A">Appendix A</a>. Detailed Classification of Header Fields............. <a href="#page-17">17</a>
<a href="#appendix-B">Appendix B</a>. Detailed Format of the CCE Packet Type............... <a href="#page-20">20</a>
Author's Address.................................................. <a href="#page-22">22</a>
Full Copyright Statement.......................................... <a href="#page-23">23</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The ROHC WG has developed a header compression framework on top of
which various profiles can be defined for different protocol sets or
compression strategies. Due to the demands of the cellular industry
for an efficient way to transport voice over IP over wireless, ROHC
[<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>] has mainly focused on compression of IP/UDP/RTP headers, which
are generous in size, especially compared to the payloads often
carried by packets with these headers.
ROHC RTP has become a very efficient, robust, and capable compression
scheme, able to compress the headers down to a total size of one
octet only. Also, transparency is guaranteed to an extremely high
extent, even when residual bit errors are present in compressed
headers delivered to the decompressor.
UDP-Lite [<a href="#ref-4" title=""The Lightweight User Datagram Protocol (UDP-Lite)"">4</a>] is a transport protocol similar to the UDP protocol [<a href="#ref-7" title=""User Datagram Protocol"">7</a>].
UDP-Lite is useful for applications designed with the capability to
tolerate errors in the payload, for which receiving damaged data is
better than dealing with the loss of entire packets. This may be
particularly suitable when packets are transported over link
technologies in which data can be partially damaged, such as wireless
links.
<span class="grey">Pelletier Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4019">RFC 4019</a> ROHC: Profiles for UDP-Lite April 2005</span>
Although these transport protocols are very similar, ROHC profiles
must be defined separately for robust compression of UDP-Lite headers
because UDP-Lite does not share the same protocol identifier with
UDP. Also, the UDP-Lite Checksum Coverage field does not share the
semantics of the corresponding UDP Length field, and as a consequence
it cannot always be inferred anymore.
This document defines two ROHC profiles for efficient compression of
UDP-Lite headers. The objective of this document is to provide
simple modifications to the corresponding ROHC profiles for UDP,
specified in <a href="./rfc3095">RFC 3095</a> [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>]. In addition, the ROHC profiles for UDP-
Lite support some of the mechanisms defined in the profile for
compression of IP headers [<a href="#ref-3" title=""RObust Header Compression (ROHC): A Compression Profile for IP"">3</a>] (ROHC IP-Only). This specification
includes support for compression of multiple IP headers and for
compressing IP-ID fields with constant behavior, as well as improved
mode transition logic and a feedback option for decompressors with
limited memory resources.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD, "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="#ref-1" title=""Key words for use in RFCs to Indicate Requirement Levels"">1</a>].
ROHC RTP : RTP/UDP/IP profile 0x0001 defined in <a href="./rfc3095">RFC 3095</a> [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>].
ROHC UDP : UDP/IP profile 0x0002 defined in <a href="./rfc3095">RFC 3095</a> [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>].
ROHC UDP-Lite : UDP-Lite/IP profile defined in this document.
ROHC RTP/UDP-Lite: RTP/UDP-Lite/IP profile defined in this document.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Background</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Overview of the UDP-Lite Protocol</span>
UDP-Lite is a transport protocol defined as an independent variant of
the UDP transport protocol. UDP-Lite is very similar to UDP, and it
allows applications that can tolerate errors in the payload to use a
checksum with an optional partial coverage. This is particularly
useful with IPv6 [<a href="#ref-6" title=""Internet Protocol, Version 6 (IPv6) Specification"">6</a>], in which the use of the transport-layer
checksum is mandatory.
UDP-Lite replaces the Length field of the UDP header with a Checksum
Coverage field. This field indicates the number of octets covered by
the 16-bit checksum, which is applied on a per-packet basis. The
coverage area always includes the UDP-Lite header and may cover the
entire packet, in which case UDP-Lite becomes semantically identical
to UDP. UDP-Lite and UDP do not share the same protocol identifier.
<span class="grey">Pelletier Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4019">RFC 4019</a> ROHC: Profiles for UDP-Lite April 2005</span>
The UDP-Lite header format:
0 15 16 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| Checksum | |
| Coverage | Checksum |
+--------+--------+--------+--------+
| |
: Payload :
| |
+-----------------------------------+
Like the UDP checksum, the UDP-Lite checksum is an end-to-end
mechanism against erroneous delivery of error sensitive data. This
checksum is mandatory with IPv6 [<a href="#ref-5" title=""Internet Protocol"">5</a>] for both protocols. However,
unlike its UDP counterpart, the UDP-Lite checksum may not be
transmitted as all zeroes and cannot be disabled for IPv4 [<a href="#ref-5" title=""Internet Protocol"">5</a>]. For
UDP, if the checksum is disabled (IPv4 only), the Checksum field
maintains a constant value and is normally not sent by the header
compression scheme. If the UDP checksum is enabled (mandatory for
IPv6), such an unpredictable field cannot be compressed and is sent
uncompressed. The UDP Length field, however, is always redundant and
can be provided by the IP module. Header compression schemes do not
normally transmit any bits of information for this field, as its
value can be inferred from the link layer.
For UDP-Lite, the checksum also has unpredictable values, and this
field must always be included as-is in the compressed header for both
IPv4 and IPv6. Furthermore, as the UDP Length field is redefined as
the Checksum Coverage field by UDP-Lite, this leads to different
properties for this field from a header-compression perspective.
The following summarizes the relationship between UDP and UDP-Lite:
- UDP-Lite and UDP have different protocol identifiers.
- The UDP-Lite checksum cannot be disabled for IPv4.
- UDP-Lite redefines the UDP Length field as the Checksum Coverage
field, with different semantics.
- UDP-Lite is semantically equivalent to UDP when the Checksum
Coverage field indicates the total length of the packet.
The next section provides a more detailed discussion of the behavior
of the Checksum Coverage field of UDP-Lite in relation to header
compression.
<span class="grey">Pelletier Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4019">RFC 4019</a> ROHC: Profiles for UDP-Lite April 2005</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Expected Behaviours of UDP-Lite Flows</span>
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. Per-Packet Behavior</span>
As mentioned in the previous section, the checksum coverage value is
applied independently of other packets that may belong to the same
flow. Specifically, the value of the checksum coverage may indicate
that the UDP-Lite packet is either entirely covered by the checksum
or covered up to some boundary less than the packet size but
including the UDP-Lite header.
<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>. Inter-Packet Behavior</span>
In relation to each other, UDP-Lite packets may exhibit one of three
possible change patterns, where within a sequence of packets the
value of the Checksum Coverage field is
1. changing, while covering the entire packet;
2. unchanging, covering up to a fixed boundary within the packet; or
3. changing, but it does not follow any specific pattern.
The first pattern above corresponds to the semantics of UDP, when the
UDP checksum is enabled. For this case, the checksum coverage field
varies according to the packet length and may be inferred from the IP
header, as is the UDP Length field value.
The second pattern corresponds to the case where the coverage is the
same from one packet to another within a particular sequence. For
this case, the Checksum Coverage field may be a static value defined
in the context, and it does not have to be sent in the compressed
header. For the third case, no useful change pattern can be
identified from packet to packet for the value of the checksum
coverage field, and it must be included in the compressed header.
<span class="h4"><a class="selflink" id="section-3.2.3" href="#section-3.2.3">3.2.3</a>. Per-Flow behavior</span>
It can be expected that any one of the above change patterns for
sequences of packets may be predominant at any time during the
lifetime of the UDP-Lite flow. A flow that predominantly follows the
first two change patterns described above may provide opportunities
for compressing the Checksum Coverage field for most of the packets.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Header Field Classification</span>
In relation to the header field classification of <a href="./rfc3095">RFC 3095</a> [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>], the
first two patterns represent the case where the value of the Checksum
Coverage field behavior is fixed and may be either INFERRED (pattern
<span class="grey">Pelletier Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4019">RFC 4019</a> ROHC: Profiles for UDP-Lite April 2005</span>
1) or STATIC (pattern 2). Pattern 3 is for the case where the value
varies unpredictably, the field is CHANGING, and the value must be
sent along with every packet.
Additional information regarding the analysis of the behavior of the
UDP-Lite fields may be found in <a href="#appendix-A">Appendix A</a>.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Rationale behind the Design of ROHC Profiles for UDP-Lite</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Design Motivations</span>
Simplicity is a strong motivation for the design of the UDP-Lite
header compression profiles. The profiles defined for UDP-Lite
should entail only a few simple modifications to the corresponding
profiles defined for UDP in <a href="./rfc3095">RFC 3095</a> [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>]. In addition, it is
desirable to include some of the improvements found in the ROHC IP-
Only profile [<a href="#ref-3" title=""RObust Header Compression (ROHC): A Compression Profile for IP"">3</a>]. Finally, whenever UDP-Lite is used in a manner
that is semantically identical to UDP, the compression efficiency
should be similar.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. ROHC Considerations</span>
The simplest approach to the definition of ROHC profiles for UDP-Lite
is to treat the Checksum Coverage field as an irregular value, and to
send it uncompressed for every packet. This may be achieved simply
by adding the field to the definition of the general packet format
[<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>]. However, then the compression efficiency would always be less
than for UDP.
Some care should be given to achieve compression efficiency for UDP-
Lite similar to that for UDP when the Checksum Coverage field behaves
like the UDP Length field. This requires the possibility to infer
the Checksum Coverage field when it is equal to the length of the
packet. Otherwise, this would put the UDP-Lite protocol at a
disadvantage over links where header compression is used, when its
behavior is made similar to the semantics of UDP.
A mechanism to detect the presence of the Checksum Coverage field in
compressed headers is thus needed. This is achieved by defining a
new packet type with the identifiers left unused in <a href="./rfc3095">RFC 3095</a> [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>].
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. ROHC Profiles for UDP-Lite</span>
This section defines two ROHC profiles:
- RTP/UDP-Lite/IP compression (profile 0x0007)
- UDP-Lite/IP compression (profile 0x0008)
<span class="grey">Pelletier Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4019">RFC 4019</a> ROHC: Profiles for UDP-Lite April 2005</span>
These profiles build on the specifications found in <a href="./rfc3095">RFC 3095</a> [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>],
with as little modification as possible. Unless it is explicitly
stated otherwise, the profiles defined herein follow the
specifications of ROHC UDP and ROHC RTP, respectively.
Note also that this document reuses the notation found in [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>].
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Context Parameters</span>
As described in [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>], information about previous packets is maintained
in a context. This includes information describing the packet stream
and compression parameters. Although the UDP and UDP-Lite protocols
share many commonalities, the differences in semantics as described
earlier render the following parameter inapplicable:
The parameter context(UDP Checksum)
The UDP-Lite checksum cannot be disabled, as opposed to UDP. The
parameter context(UDP Checksum) defined in [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>] (<a href="#section-5.7">section 5.7</a>) is
therefore not used for compression of UDP-Lite.
In addition, the UDP-Lite checksum is always sent as-is in every
compressed packet. However, the Checksum Coverage field may not
always be sent in each compressed packet, and the following context
parameter is used to indicate whether the field is sent:
The parameter context(UDP-Lite Coverage Field Present)
Whether the UDP-Lite Checksum Coverage field is present or not in
the general packet format (see <a href="#section-5.3.1">section 5.3.1</a>) is controlled by the
value of the Coverage Field Present (CFP) flag in the context.
If context(CFP) is nonzero, the Checksum Coverage field is not
compressed, and it is present within compressed packets. If
context(CFP) is zero, the Checksum Coverage field is compressed,
and it is not sent. This is the case when the value of the
Checksum Coverage field follows a stable inter-packet change
pattern; the field has either a constant value or it has a value
equal to the packet length for most packets in a sequence (see
<a href="#section-3.2">section 3.2</a>).
Finally, the following context parameter is needed to indicate
whether the field should be inferred or taken from a value previously
saved in the context:
<span class="grey">Pelletier Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4019">RFC 4019</a> ROHC: Profiles for UDP-Lite April 2005</span>
The parameter context(UDP-Lite Coverage Field Inferred)
When the UDP-Lite Checksum Coverage field is not present in the
compressed header (CFP=0), whether it is inferred is controlled by
the value of the Coverage Field Inferred (CFI) flag in the context.
If context(CFI) is nonzero, the Checksum Coverage field is inferred
from the packet length, similarly as for the UDP Length field in
ROHC RTP. If context(CFI) is zero, the Checksum Coverage field is
decompressed by using context(UDP-Lite Checksum Coverage).
Therefore, when context(CFI) is updated to a nonzero value, the
value of the Checksum Coverage field stored in the context must
also be updated.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Initialization</span>
Unless it is stated otherwise, the mechanisms of ROHC RTP and ROHC
UDP found in [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>] are used also for the ROHC RTP/UDP-Lite and the ROHC
UDP-Lite profiles, respectively.
In particular, the considerations of ROHC UDP regarding the UDP SN
taking the role of the RTP Sequence Number apply to ROHC UDP-Lite.
Also, the static context for ROHC UDP-Lite may be initialized by
reusing an existing context belonging to a stream compressed by using
ROHC RTP/UDP-Lite (profile 0x0007), similarly as for ROHC UDP.
<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>. Initialization of the UDP-Lite Header [<a href="#ref-1" title=""Key words for use in RFCs to Indicate Requirement Levels"">1</a>]</span>
The structure of the IR and IR-DYN packets and the initialization
procedures are the same as for the ROHC profiles for UDP [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>], with
the exception of the dynamic part as specified for UDP. A 2-octet
field containing the checksum coverage is added before the Checksum
field. This affects the format of dynamic chains in both IR and IR-
DYN packets.
Dynamic part:
+---+---+---+---+---+---+---+---+
/ Checksum Coverage / 2 octets
+---+---+---+---+---+---+---+---+
/ Checksum / 2 octets
+---+---+---+---+---+---+---+---+
CRC-DYNAMIC: Checksum Coverage field, Checksum field (octets 5 - 8).
CRC-STATIC: All other fields (octets 1 - 4).
<span class="grey">Pelletier Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4019">RFC 4019</a> ROHC: Profiles for UDP-Lite April 2005</span>
<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>. Compressor and Decompressor Logic</span>
The following logic must be used by both the compressor and the
decompressor for assigning values to the parameters context(CFP) and
context(CFI) during initialization:
Context(CFP)
During context initialization, the value of context(CFP) MUST be
set to a nonzero value if the Checksum Coverage field differs from
the length of the UDP-Lite packet, for any one IR or IR-DYN packet
sent (compressor) or received (decompressor); otherwise, the value
MUST be set to zero.
Context(CFI)
During context initialization, the value of context(CFI) MUST be
set to a nonzero value if the Checksum Coverage field is equal to
the length of the UDP-Lite packet within an IR or an IR-DYN packet
sent (compressor) or received (decompressor); otherwise, the value
MUST be set to zero.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Packet Formats</span>
The general packet format, as defined in <a href="./rfc3095">RFC 3095</a> [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>], is modified to
include an additional field for the UDP-Lite checksum coverage. A
packet type is also defined to handle the specific semantics and
characteristics of this field.
<span class="h4"><a class="selflink" id="section-5.3.1" href="#section-5.3.1">5.3.1</a>. General Packet Format</span>
The general packet format of a compressed ROHC UDP-Lite header is
similar to the compressed ROHC RTP header ([<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>], section 5.7), with
modifications to the Checksum field, as well as additional fields for
handling multiple IP headers and for the UDP-Lite checksum coverage:
<span class="grey">Pelletier Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4019">RFC 4019</a> ROHC: Profiles for UDP-Lite April 2005</span>
--- --- --- --- --- --- --- ---
: List of : variable, given by static chain
/ dynamic chains / (does not include SN)
: for additional IP headers : see also [<a href="#ref-3" title=""RObust Header Compression (ROHC): A Compression Profile for IP"">3</a>], section 3.2.
--- --- --- --- --- --- --- ---
: : 2 octets,
+ UDP-Lite Checksum Coverage + if context(CFP) = 1 or
: : if packet type = CCE (see 5.3.2)
--- --- --- --- --- --- --- ---
: :
+ UDP-Lite Checksum + 2 octets
: :
--- --- --- --- --- --- --- ---
The list of dynamic header chains carries the dynamic header part for
each IP header in excess of the initial two, if there is any (as
indicated by the presence of corresponding header parts in the static
chain). Note that there is no sequence number at the end of the
chain, as SN is present within compressed base headers.
The order of the fields following the optional extension of the
general ROHC packet format is the same as the order between the
fields in the uncompressed header.
When the CRC is calculated, the Checksum Coverage field is CRC-
DYNAMIC.
<span class="h4"><a class="selflink" id="section-5.3.2" href="#section-5.3.2">5.3.2</a>. Packet Type CCE: CCE(), CCE(ON), and CCE(OFF)</span>
The ROHC profiles for UDP-Lite define a packet type to handle the
various possible change patterns of the checksum coverage. This
packet type may be used to manipulate the context values that control
the presence of the Checksum Coverage field within the general packet
format (i.e., context(CFP)) and how the field is decompressed (i.e.,
context(CFI)). The 2-octet Checksum Coverage field is always present
within the format of this packet (see <a href="#section-5.3.1">section 5.3.1</a>).
This type of packet is named Checksum Coverage Extension, or CCE, and
its updating properties depend on the final two bits of the packet
type octet (see format below). A naming scheme of the form
CCE(<some_property>) is used to uniquely identify the properties of a
particular CCE packet.
Although this packet type defines its own format, it may be
considered as an extension mechanism for packets of type 2, 1, or 0
[<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>]. This is achieved by substitution of the packet type identifier
of the first octet of the base header (the "outer" identifier) with
<span class="grey">Pelletier Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4019">RFC 4019</a> ROHC: Profiles for UDP-Lite April 2005</span>
one of the unused packet types from <a href="./rfc3095">RFC 3095</a> [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>]. The substituted
identifier is then moved to the first octet of the remainder of the
base header (the "inner" identifier).
The format of the ROHC UDP-Lite CCE packet type is as follows:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 F | K | Outer packet type identifier
+===+===+===+===+===+===+===+===+
: : (with inner type identifier)
/ Inner Base header / variable number of bits, given by
: : the inner packet type identifier
+---+---+---+---+---+---+---+---+
F,K: F,K = 00 is reserved at framework level (IR-DYN);
F,K = 01 indicates CCE();
F,K = 10 indicates CCE(ON);
F,K = 11 indicates CCE(OFF).
Updating properties: The updating properties of the inner packet
type carried within any of the CCE packets are always
maintained. CCE(ON) and CCE(OFF) MUST NOT be used to extend
R-0 and R-1* headers. In addition, CCE(ON) always updates
context(CFP); CCE(OFF) always updates context(CFP),
context(CFI), and context(UDP-Lite Checksum Coverage).
<a href="#appendix-B">Appendix B</a> provides an expanded view of the resulting format of the
CCE packet type.
<span class="h5"><a class="selflink" id="section-5.3.2.1" href="#section-5.3.2.1">5.3.2.1</a>. Properties of CCE()</span>
Aside from the updating properties of the inner packet type carried
within CCE(), this packet does not update any other context values.
CCE() thus is mode-agnostic; e.g., it can extend any of packet types
2, 1, and 0, regardless of the current mode of operation [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>].
CCE() may be used when the checksum coverage deviates from the change
pattern assumed by the compressor, where the field could previously
be compressed. This packet is useful if the occurrence of such
deviations is rare.
<span class="h5"><a class="selflink" id="section-5.3.2.2" href="#section-5.3.2.2">5.3.2.2</a>. Properties of CCE(ON)</span>
In addition to the updating properties of the inner packet type,
CCE(ON) updates context(CFP) to a nonzero value; i.e., it effectively
turns on the presence of the Checksum Coverage field within the
<span class="grey">Pelletier Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4019">RFC 4019</a> ROHC: Profiles for UDP-Lite April 2005</span>
general packet format. This is useful when the predominant change
pattern of the checksum coverage precludes its compression.
CCE(ON) can extend any of the context-updating packets of type 2, 1,
and 0; that is, packets with a compressed header containing a CRC
[<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>]. Specifically, R-0 and R-1* headers MUST NOT be extended by
using CCE(ON).
<span class="h5"><a class="selflink" id="section-5.3.2.3" href="#section-5.3.2.3">5.3.2.3</a>. Properties of CCE(OFF)</span>
In addition to the updating properties of the inner packet type,
CCE(OFF) updates context(CFP) to a value of zero; i.e., it
effectively turns off the presence of the Checksum Coverage field
within the general packet format. This is useful when the change
pattern of the checksum coverage seldom deviates from the pattern
assumed by the compressor.
CCE(OFF) also updates context(CFI) to a nonzero value, if field(UDP-
Lite Checksum Coverage) is equal to the packet length; otherwise, it
must be set to zero. Note that when context(CFI) is updated by using
packet type CCE(OFF), a match of field(Checksum Coverage) with the
packet length always has precedence over a match with
context(Checksum Coverage). Finally, context(UDP-Lite Checksum
Coverage) is also updated by CCE(OFF).
Similarly to CCE(ON), CCE(OFF) can extend any of the context updating
packets of type 2, 1, and 0 [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>].
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Compressor Logic</span>
If hdr(UDP-Lite Checksum Coverage) is different from context(UDP-Lite
Checksum Coverage) and different from the packet length when
context(CFP) is zero, the Checksum Coverage field cannot be
compressed. In addition, if hdr(UDP-Lite Checksum Coverage) is
different from the packet length when context(CFP) is zero and
context(CFI) is nonzero, the Checksum Coverage field cannot be
compressed by either. For both cases, the field must be sent
uncompressed using a CCE packet, or the context must be reinitialized
by using an IR packet.
<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>. Decompressor Logic</span>
For packet types other than IR, IR-DYN, and CCE that are received
when the value of context(CFP) is zero, the Checksum Coverage field
must be decompressed by using the value stored in the context if the
value of context(CFI) is zero; otherwise, the field is inferred from
the length of the UDP-Lite packet derived from the IP module.
<span class="grey">Pelletier Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4019">RFC 4019</a> ROHC: Profiles for UDP-Lite April 2005</span>
<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a>. Additional Mode Transition Logic</span>
The profiles defined in this document allow the compressor to decline
a mode transition requested by the decompressor. This is achieved by
redefining the Mode parameter for the value mode = 0 (in packet types
UOR-2, IR, and IR-DYN) as follows (see also [<a href="#ref-3" title=""RObust Header Compression (ROHC): A Compression Profile for IP"">3</a>], section 3.4):
Mode: Compression mode. 0 = (C)ancel Mode Transition
Upon receiving the Mode parameter set to 0, the decompressor MUST
stay in its current mode of operation and SHOULD refrain from sending
further mode transition requests for the declined mode.
<span class="h3"><a class="selflink" id="section-5.7" href="#section-5.7">5.7</a>. The CONTEXT_MEMORY Feedback Option</span>
This feedback option informs the compressor that the decompressor
does not have sufficient memory resources to handle the context of
the packet stream required by the current compressed structure.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type = 9 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
When receiving a CONTEXT_MEMORY option, the compressor SHOULD take
actions to compress the packet stream in a way that requiring less
decompressor memory resources or stop compressing the packet stream.
<span class="h3"><a class="selflink" id="section-5.8" href="#section-5.8">5.8</a>. Constant IP-ID</span>
The profiles for UDP-Lite support compression of the IP-ID field with
constant behavior, with the addition of the Static IP Identifier
(SID) flag within the dynamic part of the chain used to initialize
the IPv4 header, as follows (see also [<a href="#ref-3" title=""RObust Header Compression (ROHC): A Compression Profile for IP"">3</a>], section 3.3):
Dynamic part:
+---+---+---+---+---+---+---+---+
| Type of Service |
+---+---+---+---+---+---+---+---+
| Time to Live |
+---+---+---+---+---+---+---+---+
/ Identification / 2 octets
+---+---+---+---+---+---+---+---+
| DF|RND|NBO|SID| 0 |
+---+---+---+---+---+---+---+---+
/ Generic extension header list / variable length
+---+---+---+---+---+---+---+---+
<span class="grey">Pelletier Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4019">RFC 4019</a> ROHC: Profiles for UDP-Lite April 2005</span>
SID: Static IP Identifier.
For IR and IR-DYN packets:
The logic is the same as that for the respective ROHC
profiles for UDP, with the addition that field (SID)
must be kept in the context.
For compressed headers other than IR and IR-DYN:
If value(RND) = 0 and context(SID) = 0, hdr(IP-ID) is
compressed by using Offset IP-ID encoding (see [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>], <a href="#section-4.5.5">section</a>
<a href="#section-4.5.5">4.5.5</a>) using p = 0 and default-slope(IP-ID offset) = 0.
If value(RND) = 0 and context(SID) = 1, hdr(IP-ID) is constant
and compressed away; hdr(IP-ID) is the value of context(IP-ID).
If value(RND) = 1, IP-ID is the uncompressed hdr(IP-ID). IP-ID
is then passed as additional octets at the end of the
compressed header, after any extensions.
Note: Only IR and IR-DYN packets can update context(SID).
Note: All other fields are the same as for the respective ROHC
profiles for UDP [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>].
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
The security considerations of <a href="./rfc3095">RFC 3095</a> [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>] apply integrally to this
document, without modification.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
ROHC profile identifiers 0x0007 (ROHC RTP/UDP-Lite) and 0x0008 (ROHC
UDP-Lite) have been reserved by the IANA for the profiles defined in
this document (<a href="./rfc4019">RFC 4019</a>).
Two ROHC profile identifiers must be reserved by the IANA for the
profiles defined in this document. Since profile number 0x0006 is
being saved for the TCP/IP (ROHC-TCP) profile, profile numbers 0x0007
and 0x0008 are the most suitable unused identifiers available, and
should thus be used. As for previous ROHC profiles, profile numbers
0xnn07 and 0xnn08 must also be reserved for future variants of these
profiles. The registration suggested for the "RObust Header
Compression (ROHC) Profile Identifiers" name space:
<span class="grey">Pelletier Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4019">RFC 4019</a> ROHC: Profiles for UDP-Lite April 2005</span>
OLD: 0x0006-0xnn7F To be Assigned by IANA
NEW: 0xnn06 To be Assigned by IANA
0x0007 ROHC RTP/UDP-Lite [<a href="./rfc4019">RFC4019</a>]
0xnn07 Reserved
0x0008 ROHC UDP-Lite [<a href="./rfc4019">RFC4019</a>]
0xnn08 Reserved
0x0009-0xnn7F To be Assigned by IANA
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgments</span>
The author would like to thank Lars-Erik Jonsson, Kristofer Sandlund,
Mark West, Richard Price, Gorry Fairhurst, Fredrik Linstroem and Mats
Nordberg for useful reviews and discussions around this document.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-1">1</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-2">2</a>] 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):
Framework and four profiles: RTP, UDP, ESP, and uncompressed",
<a href="./rfc3095">RFC 3095</a>, July 2001.
[<a id="ref-3">3</a>] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
(ROHC): A Compression Profile for IP", <a href="./rfc3843">RFC 3843</a>, June 2004.
[<a id="ref-4">4</a>] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G.
Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)",
<a href="./rfc3828">RFC 3828</a>, July 2004.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-5">5</a>] Postel, J., "Internet Protocol", STD 5, <a href="./rfc791">RFC 791</a>, September 1981.
[<a id="ref-6">6</a>] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", <a href="./rfc2460">RFC 2460</a>, December 1998.
[<a id="ref-7">7</a>] Postel, J., "User Datagram Protocol", STD 6, <a href="./rfc768">RFC 768</a>, August
1980.
<span class="grey">Pelletier Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4019">RFC 4019</a> ROHC: Profiles for UDP-Lite April 2005</span>
[<a id="ref-8">8</a>] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
<a href="./rfc3550">RFC 3550</a>, July 2003.
<span class="grey">Pelletier Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4019">RFC 4019</a> ROHC: Profiles for UDP-Lite April 2005</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Detailed Classification of Header Fields</span>
This section summarizes the difference from the classification found
in the corresponding appendix in <a href="./rfc3095">RFC 3095</a> [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>] and similarly provides
conclusions about how the various header fields should be handled by
the header compression scheme to optimize compression and
functionality. These conclusions are separated based on the behavior
of the UDP-Lite Checksum Coverage field and use the expected change
patterns described in <a href="#section-3.2">section 3.2</a> of this document.
<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>. UDP-Lite Header Fields</span>
The following table summarizes a possible classification for the UDP-
Lite header fields in comparison with the classification for UDP,
using the same classes as in <a href="./rfc3095">RFC 3095</a> [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>].
Header fields of UDP-Lite and UDP:
+-------------------+-------------+
| UDP-Lite | UDP |
+-------------------+--------+-------------------+-------------+
| Header | Size | Class | Class |
| Field | (bits) | | |
+-------------------+--------+-------------------+-------------+
| Source Port | 16 | STATIC-DEF | STATIC-DEF |
| Destination Port | 16 | STATIC-DEF | STATIC-DEF |
| Checksum Coverage | 16 | INFERRED | |
| | | STATIC | |
| | | CHANGING | |
| Length | 16 | | INFERRED |
| Checksum | 16 | CHANGING | CHANGING |
+-------------------+--------+-------------------+-------------+
Source and Destination Port
Same as for UDP. Specifically, these fields are part of the
definition of a stream and must thus be constant for all packets in
the stream. The fields are therefore classified as STATIC-DEF.
Checksum Coverage
This field specifies which part of the UDP-Lite datagram is covered
by the checksum. It may have a value of zero or be equal to the
datagram length if the checksum covers the entire datagram, or it
may have any value between eight octets and the length of the
datagram to specify the number of octets protected by the checksum,
<span class="grey">Pelletier Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4019">RFC 4019</a> ROHC: Profiles for UDP-Lite April 2005</span>
calculated from the first octet of the UDP-Lite header. The value
of this field may vary for each packet, and this makes the value
unpredictable from a header-compression perspective.
Checksum
The information used for the calculation of the UDP-Lite checksum
is governed by the value of the checksum coverage and minimally
includes the UDP-Lite header. The checksum is a changing field
that must always be sent as-is.
The total size of the fields in each class, for each expected change
pattern (see <a href="#section-3.2">section 3.2</a>), is summarized in the tables below:
Pattern 1:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| INFERRED | 2 | Checksum Coverage
| STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 2 | Checksum
+------------+---------------+
Pattern 2:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| STATIC-DEF | 4 | Source Port / Destination Port
| STATIC | 2 | Checksum Coverage
| CHANGING | 2 | Checksum
+------------+---------------+
Pattern 3:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 4 | Checksum Coverage / Checksum
+------------+---------------+
<span class="grey">Pelletier Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc4019">RFC 4019</a> ROHC: Profiles for UDP-Lite April 2005</span>
<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>. Header Compression Strategies for UDP-Lite</span>
The following table revisits the corresponding table (table A.1) for
UDP from [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>] (section A.2) and classifies the changing fields based
on the change patterns previously identified in <a href="#section-3.2">section 3.2</a>.
Header compression strategies for UDP-Lite:
+----------+---------+-------------+-----------+-----------+
| Field | Pattern | Value/Delta | Class | Knowledge |
+==========+=========+=============+===========+===========+
| | #1 | Value | CHANGING | INFERRED |
| Checksum |---------+-------------+-----------+-----------+
| Coverage | #2 | Value | RC | UNKNOWN |
| |---------+-------------+-----------+-----------+
| | #3 | Value | IRREGULAR | UNKNOWN |
+----------+---------+-------------+-----------+-----------+
| Checksum | All | Value | IRREGULAR | UNKNOWN |
+----------+---------+-------------+-----------+-----------+
<span class="h4"><a class="selflink" id="appendix-A.2.1" href="#appendix-A.2.1">A.2.1</a>. Transmit initially but be prepared to update</span>
UDP-Lite Checksum Coverage (Patterns #1 and #2)
<span class="h4"><a class="selflink" id="appendix-A.2.2" href="#appendix-A.2.2">A.2.2</a>. Transmit as-is in all packets</span>
UDP-Lite Checksum
UDP-Lite Checksum Coverage (Pattern #3)
<span class="grey">Pelletier Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc4019">RFC 4019</a> ROHC: Profiles for UDP-Lite April 2005</span>
<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>. Detailed Format of the CCE Packet Type</span>
This section provides an expanded view of the format of the CCE
packet, based on the general ROHC RTP compressed header [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>] and the
general format of a compressed header of the ROHC IP-Only profile
[<a href="#ref-3" title=""RObust Header Compression (ROHC): A Compression Profile for IP"">3</a>]. The modifications necessary to carry the base header of a
packet of type 2, 1 or 0 [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>] within the CCE packet format, along with
the additional fields to properly handle compression of multiple IP
headers, result in the following structure for the CCE packet type:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : If for small CIDs and CID 1 - 15
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 F | K | Outer packet type identifier
+---+---+---+---+---+---+---+---+
: :
/ 0, 1, or 2 octets of CID / 1 - 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
| First octet of base header | (with "inner" type indication)
+---+---+---+---+---+---+---+---+
/ Remainder of base header / Variable number of bits
+---+---+---+---+---+---+---+---+
<span class="grey">Pelletier Standards Track [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc4019">RFC 4019</a> ROHC: Profiles for UDP-Lite April 2005</span>
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: :
/ Extension / See <a href="./rfc3095">RFC 3095</a> [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>], section 5.7.
: :
--- --- --- --- --- --- --- ---
: :
+ IP-ID of outer IPv4 header + See <a href="./rfc3095">RFC 3095</a> [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>], section 5.7.
: :
--- --- --- --- --- --- --- ---
/ AH data for outer list / See <a href="./rfc3095">RFC 3095</a> [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>], section 5.7.
--- --- --- --- --- --- --- ---
: :
+ GRE checksum + See <a href="./rfc3095">RFC 3095</a> [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>], section 5.7.
: :
--- --- --- --- --- --- --- ---
: :
+ IP-ID of inner IPv4 header + See <a href="./rfc3095">RFC 3095</a> [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>], section 5.7.
: :
--- --- --- --- --- --- --- ---
/ AH data for inner list / See <a href="./rfc3095">RFC 3095</a> [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>], section 5.7.
--- --- --- --- --- --- --- ---
: :
+ GRE checksum + See <a href="./rfc3095">RFC 3095</a> [<a href="#ref-2" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed"">2</a>], section 5.7.
: :
--- --- --- --- --- --- --- ---
: List of : Variable, given by static chain
/ dynamic chains / (includes no SN).
: for additional IP headers : See [<a href="#ref-3" title=""RObust Header Compression (ROHC): A Compression Profile for IP"">3</a>], section 3.2.
--- --- --- --- --- --- --- ---
: :
+ UDP-Lite Checksum Coverage + 2 octets
: :
+---+---+---+---+---+---+---+---+
: :
+ UDP-Lite Checksum + 2 octets
: :
+---+---+---+---+---+---+---+---+
F,K: F,K = 00 is reserved at framework level (IR-DYN);
F,K = 01 indicates CCE();
F,K = 10 indicates CCE(ON);
F,K = 11 indicates CCE(OFF).
Note that this document does not define (F,K) = 00, as this would
collide with the IR-DYN packet type already reserved at the ROHC
framework level.
<span class="grey">Pelletier Standards Track [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc4019">RFC 4019</a> ROHC: Profiles for UDP-Lite April 2005</span>
Author's Address
Ghyslain Pelletier
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 840 429 43
Fax : +46 920 996 21
EMail: ghyslain.pelletier@ericsson.com
<span class="grey">Pelletier Standards Track [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc4019">RFC 4019</a> ROHC: Profiles for UDP-Lite April 2005</span>
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Pelletier Standards Track [Page 23]
</pre>
|
