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
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
|
<pre>Network Working Group B. Thompson
Request for Comments: 4170 T. Koren
BCP: 110 D. Wing
Category: Best Current Practice Cisco Systems
November 2005
<span class="h1">Tunneling Multiplexed Compressed RTP (TCRTP)</span>
Status of This Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a method to improve the bandwidth utilization
of RTP streams over network paths that carry multiple Real-time
Transport Protocol (RTP) streams in parallel between two endpoints,
as in voice trunking. The method combines standard protocols that
provide compression, multiplexing, and tunneling over a network path
for the purpose of reducing the bandwidth used when multiple RTP
streams are carried over that path.
<span class="grey">Thompson, et al. Best Current Practice [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 2005</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Is Bandwidth Costly? .......................................<a href="#page-3">3</a>
<a href="#section-1.2">1.2</a>. Overview of Protocols ......................................<a href="#page-3">3</a>
<a href="#section-1.3">1.3</a>. Document Focus .............................................<a href="#page-4">4</a>
<a href="#section-1.4">1.4</a>. Choice of Enhanced CRTP ....................................<a href="#page-4">4</a>
<a href="#section-1.5">1.5</a>. Reducing TCRTP Overhead ....................................<a href="#page-4">4</a>
<a href="#section-2">2</a>. Protocol Operation and Recommended Extensions ...................<a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. Models .....................................................<a href="#page-5">5</a>
<a href="#section-2.2">2.2</a>. Header Compression: ECRTP ..................................<a href="#page-5">5</a>
<a href="#section-2.2.1">2.2.1</a>. Synchronizing ECRTP States ..........................<a href="#page-5">5</a>
<a href="#section-2.2.2">2.2.2</a>. Out-of-Order Packets ................................<a href="#page-6">6</a>
<a href="#section-2.3">2.3</a>. Multiplexing: PPP Multiplexing .............................<a href="#page-6">6</a>
2.3.1. PPP Multiplex Transmitter Modifications for
Tunneling ...........................................<a href="#page-7">7</a>
<a href="#section-2.3.2">2.3.2</a>. Tunneling Inefficiencies ............................<a href="#page-8">8</a>
<a href="#section-2.4">2.4</a>. Tunneling: L2TP ............................................<a href="#page-8">8</a>
<a href="#section-2.4.1">2.4.1</a>. Tunneling and DiffServ ..............................<a href="#page-9">9</a>
<a href="#section-2.5">2.5</a>. Encapsulation Formats ......................................<a href="#page-9">9</a>
<a href="#section-3">3</a>. Bandwidth Efficiency ...........................................<a href="#page-10">10</a>
<a href="#section-3.1">3.1</a>. Multiplexing Gains ........................................<a href="#page-10">10</a>
<a href="#section-3.2">3.2</a>. Packet Loss Rate ..........................................<a href="#page-10">10</a>
<a href="#section-3.3">3.3</a>. Bandwidth Calculation for Voice and Video Applications ....<a href="#page-10">10</a>
<a href="#section-3.3.1">3.3.1</a>. Voice Bandwidth Calculation Example ................<a href="#page-12">12</a>
<a href="#section-3.3.2">3.3.2</a>. Voice Bandwidth Comparison Table ...................<a href="#page-13">13</a>
<a href="#section-3.3.3">3.3.3</a>. Video Bandwidth Calculation Example ................<a href="#page-13">13</a>
<a href="#section-3.3.4">3.3.4</a>. TCRTP over ATM .....................................<a href="#page-14">14</a>
<a href="#section-3.3.5">3.3.5</a>. TCRTP over Non-ATM Networks ........................<a href="#page-14">14</a>
<a href="#section-4">4</a>. Example Implementation of TCRTP ................................<a href="#page-15">15</a>
<a href="#section-4.1">4.1</a>. Suggested PPP and L2TP Negotiation for TCRTP ..............<a href="#page-17">17</a>
<a href="#section-4.2">4.2</a>. PPP Negotiation TCRTP .....................................<a href="#page-17">17</a>
<a href="#section-4.2.1">4.2.1</a>. LCP Negotiation ....................................<a href="#page-17">17</a>
<a href="#section-4.2.2">4.2.2</a>. IPCP Negotiation ...................................<a href="#page-18">18</a>
<a href="#section-4.3">4.3</a>. L2TP Negotiation ..........................................<a href="#page-19">19</a>
<a href="#section-4.3.1">4.3.1</a>. Tunnel Establishment ...............................<a href="#page-19">19</a>
<a href="#section-4.3.2">4.3.2</a>. Session Establishment ..............................<a href="#page-19">19</a>
<a href="#section-4.3.3">4.3.3</a>. Tunnel Tear Down ...................................<a href="#page-20">20</a>
<a href="#section-5">5</a>. Security Considerations ........................................<a href="#page-20">20</a>
<a href="#section-6">6</a>. Acknowledgements ...............................................<a href="#page-21">21</a>
<a href="#section-7">7</a>. References .....................................................<a href="#page-21">21</a>
<a href="#section-7.1">7.1</a>. Normative References ......................................<a href="#page-21">21</a>
<a href="#section-7.2">7.2</a>. Informative References ....................................<a href="#page-22">22</a>
<span class="grey">Thompson, et al. Best Current Practice [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 2005</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document describes a way to combine existing protocols for
compression, multiplexing, and tunneling to save bandwidth for some
RTP applications.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Is Bandwidth Costly?</span>
On certain links, such as customer access links, the cost of
bandwidth is widely acknowledged to be a significant concern.
protocols such as CRTP (Compressed RTP, [<a href="#ref-CRTP" title=""Compressing IP/UDP/RTP Headers for Low-Speed Serial Links"">CRTP</a>]) are well suited to
help bandwidth inefficiencies of protocols such as VoIP over these
links.
Unacknowledged by many, however, is the cost of long-distance WAN
links. While some voice-over-packet technologies such as Voice over
ATM (VoAAL2, [<a href="#ref-I.363.2" title=""B-ISDN ATM Adaptation layer specification: Type 2 AAL"">I.363.2</a>]) and Voice over MPLS provide bandwidth
efficiencies (because both technologies lack IP, UDP, and RTP
headers), neither VoATM nor VoMPLS provide direct access to voice-
over-packet services available to Voice over IP. Thus, goals of WAN
link cost reduction are met at the expense of lost interconnection
opportunities to other networks.
TCRTP solves the VoIP bandwidth discrepancy, especially for large,
voice-trunking applications.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Overview of Protocols</span>
Header compression is accomplished using Enhanced CRTP (ECRTP,
[<a href="#ref-ECRTP" title=""Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering"">ECRTP</a>]). ECRTP is an enhancement to classical CRTP [<a href="#ref-CRTP" title=""Compressing IP/UDP/RTP Headers for Low-Speed Serial Links"">CRTP</a>] that
works better over long delay links, such as the end-to-end tunneling
links described in this document. This header compression reduces
the IP, UDP, and RTP headers.
Multiplexing is accomplished using PPP Multiplexing [<a href="#ref-PPP-MUX" title=""PPP Multiplexing"">PPP-MUX</a>].
Tunneling PPP is accomplished by using L2TP [<a href="#ref-L2TPv3" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">L2TPv3</a>].
CRTP operates link-by-link; that is, to achieve compression over
multiple router hops, CRTP must be employed twice on each router --
once on ingress, again on egress. In contrast, TCRTP described in
this document does not require any additional per-router processing
to achieve header compression. Instead, headers are compressed end-
to-end, saving bandwidth on all intermediate links.
<span class="grey">Thompson, et al. Best Current Practice [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 2005</span>
<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>. Document Focus</span>
This document is primarily concerned with bandwidth savings for Voice
over IP (VoIP) applications over high-delay networks. However, the
combinations of protocols described in this document can be used to
provide similar bandwidth savings for other RTP applications such as
video, and bandwidth savings are included for a sample video
application.
<span class="h3"><a class="selflink" id="section-1.4" href="#section-1.4">1.4</a>. Choice of Enhanced CRTP</span>
CRTP [<a href="#ref-CRTP" title=""Compressing IP/UDP/RTP Headers for Low-Speed Serial Links"">CRTP</a>] describes the use of RTP header compression on an
unspecified link layer transport, but typically PPP is used. For
CRTP to compress headers, it must be implemented on each PPP link. A
lot of context is required to successfully run CRTP, and memory and
processing requirements are high, especially if multiple hops must
implement CRTP to save bandwidth on each of the hops. At higher line
rates, CRTP's processor consumption becomes prohibitively expensive.
To avoid the per-hop expense of CRTP, a simplistic solution is to use
CRTP with L2TP to achieve end-to-end CRTP. However, as described in
[<a href="#ref-ECRTP" title=""Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering"">ECRTP</a>], CRTP is only suitable for links with low delay and low loss.
However, once multiple router hops are involved, CRTP's expectation
of low delay and low loss can no longer be met. Further, packets can
arrive out of order.
Therefore, this document describes the use of Enhanced CRTP [<a href="#ref-ECRTP" title=""Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering"">ECRTP</a>],
which supports high delay, both packet loss, and misordering between
the compressor and decompressor.
<span class="h3"><a class="selflink" id="section-1.5" href="#section-1.5">1.5</a>. Reducing TCRTP Overhead</span>
If only one stream is tunneled (L2TP) and compressed (ECRTP), there
are little bandwidth savings. Multiplexing is helpful to amortize
the overhead of the tunnel header over many RTP payloads. The
multiplexing format proposed by this document is PPP multiplexing
[<a href="#ref-PPP-MUX" title=""PPP Multiplexing"">PPP-MUX</a>]. See <a href="#section-2.3">Section 2.3</a> for details.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Protocol Operation and Recommended Extensions</span>
This section describes how to combine three protocols: Enhanced CRTP,
PPP Multiplexing, and L2TP Tunneling, to save bandwidth for RTP
applications such as Voice over IP.
<span class="grey">Thompson, et al. Best Current Practice [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 2005</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Models</span>
TCRTP can typically be implemented in two ways. The most
straightforward is to implement TCRTP in the gateways terminating the
RTP streams:
[voice gateway]---[voice gateway]
^
|
TCRTP over IP
Another way TCRTP can be implemented is with an external
concentration device. This device could be placed at strategic
places in the network and could dynamically create and destroy TCRTP
sessions without the participation of RTP-generating endpoints.
[voice GW]\ /[voice GW]
[voice GW]---[concentrator]---[concentrator]---[voice GW]
[voice GW]/ \[voice GW]
^ ^ ^
| | |
RTP over IP TCRTP over IP RTP over IP
Such a design also allows classical CRTP [<a href="#ref-CRTP" title=""Compressing IP/UDP/RTP Headers for Low-Speed Serial Links"">CRTP</a>] to be used on links
with only a few active flows per link (where TCRTP isn't efficient;
see <a href="#section-3">Section 3</a>):
[voice GW]\ /[voice GW]
[voice GW]---[concentrator]---[concentrator]---[voice GW]
[voice GW]/ \[voice GW]
^ ^ ^
| | |
CRTP over IP TCRTP over IP RTP over IP
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Header Compression: ECRTP</span>
As described in [<a href="#ref-ECRTP" title=""Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering"">ECRTP</a>], classical CRTP [<a href="#ref-CRTP" title=""Compressing IP/UDP/RTP Headers for Low-Speed Serial Links"">CRTP</a>] is not suitable over
long-delay WAN links commonly used when tunneling, as proposed by
this document. Thus, ECRTP should be used instead of CRTP.
<span class="h4"><a class="selflink" id="section-2.2.1" href="#section-2.2.1">2.2.1</a>. Synchronizing ECRTP States</span>
When the compressor receives an RTP packet that has an unpredicted
change in the RTP header, the compressor should send a COMPRESSED_UDP
packet (described in [<a href="#ref-ECRTP" title=""Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering"">ECRTP</a>]) to synchronize the ECRTP decompressor
state. The COMPRESSED_UDP packet updates the RTP context in the
decompressor.
<span class="grey">Thompson, et al. Best Current Practice [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 2005</span>
To ensure delivery of updates of context variables, COMPRESSED_UDP
packets should be delivered using the robust operation described in
[<a href="#ref-ECRTP" title=""Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering"">ECRTP</a>].
Because the "twice" algorithm described in [<a href="#ref-ECRTP" title=""Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering"">ECRTP</a>] relies on UDP
checksums, the IP stack on the RTP transmitter should transmit UDP
checksums. If UDP checksums are not used, the ECRTP compressor
should use the CRTP Headers checksum described in [<a href="#ref-ECRTP" title=""Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering"">ECRTP</a>].
<span class="h4"><a class="selflink" id="section-2.2.2" href="#section-2.2.2">2.2.2</a>. Out-of-Order Packets</span>
Tunneled transport does not guarantee ordered delivery of packets.
Therefore, the ECRTP decompressor must operate correctly in the
presence of out of order packets.
The order of packets for RTP is determined by the RTP sequence
number. To add robustness in case of packet loss or packet
reordering, ECRTP sends short deltas together with the full value
when updating context variables, and repeats the updates in N
packets, where N is an engineered constant tuned to the kind of pipe
ECRTP is used for.
By contrast, [<a href="#ref-ROHC" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed "">ROHC</a>] compresses out the sequence number and another
layer is necessary for [<a href="#ref-ROHC" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed "">ROHC</a>] to handle out-of-order delivery of
packets over a tunnel [<a href="#ref-REORDER" title=""RObust Header Compression (ROHC): ROHC over Channels that can Reorder Packets"">REORDER</a>].
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Multiplexing: PPP Multiplexing</span>
Both CRTP and ECRTP require a layer two protocol that allows
identifying different protocols. [<a href="#ref-PPP" title=""The Point-to-Point Protocol (PPP)"">PPP</a>] is suited for this.
When CRTP is used inside of a tunnel, the header compression
associated with CRTP will reduce the size of the IP, UDP, and IP
headers of the IP packet carried in the tunnel. However, the tunnel
itself has overhead due to its IP header and the tunnel header (the
information necessary to identify the tunneled payload). One way to
reduce the overhead of the IP header and tunnel header is to
multiplex multiple RTP payloads in a single tunneled packet.
[<a id="ref-PPP-MUX">PPP-MUX</a>] describes an encapsulation that combines multiple PPP
payloads into one multiplexed payload. PPP multiplexing allows any
supported PPP payload type to be multiplexed. This multiplexed frame
is then carried as a single PPPMUX payload in the IP tunnel. This
allows multiple RTP payloads to be carried in a single IP tunnel
packet and allows the overhead of the uncompressed IP and tunnel
headers to be amortized over multiple RTP payloads.
<span class="grey">Thompson, et al. Best Current Practice [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 2005</span>
During PPP establishment of the TCRTP tunnel, only LCP and IPCP (for
header compression) are required -- IP addresses do not need to be
negotiated, nor is authentication necessary. See <a href="#section-4.1">Section 4.1</a> for
details.
<span class="h4"><a class="selflink" id="section-2.3.1" href="#section-2.3.1">2.3.1</a>. PPP Multiplex Transmitter Modifications for Tunneling</span>
Section 1.2 of [<a href="#ref-PPP-MUX" title=""PPP Multiplexing"">PPP-MUX</a>] describes an example transmitter procedure
that can be used to implement a PPP Multiplex transmitter. The
transmission procedure described in this section includes a parameter
MAX-SF-LEN that is used to limit the maximum size of a PPP Multiplex
frame.
There are two reasons for limiting the size of a PPP Multiplex frame.
First, a PPPMUX frame should never exceed the Maximum Receive Unit
(MRU) of a physical link. Second, when a PPP session and its
associated flow control are bound to a physical link, the MAX-SF-LEN
parameter forms an upper limit on the amount of time a multiplex
packet can be held before being transmitted. When flow control for
the PPP Multiplex transmitter is bound to a physical link, the clock
rate of the physical link can be used to pull frames from the PPP
Multiplex transmitter.
This type of flow control limits the maximum amount of time a PPP
multiplex frame can be held before being transmitted to MAX-SF-LEN /
Link Speed.
Tunnel interfaces are typically not bound to physical interfaces.
Because of this, a tunnel interface has no well-known transmission
rate associated with it. This means that flow control in the PPPMUX
transmitter cannot rely on the clock of a physical link to pull
frames from the multiplex transmitter. Instead, a timer must be used
to limit the amount of time a PPPMUX frame can be held before being
transmitted. The timer along with the MAX-SF-LEN parameter should be
used to limit the amount of time a PPPMUX frame is held before being
transmitted.
The following extensions to the PPPMUX transmitter logic should be
made for use with tunnels. The flow control logic of the PPP
transmitter should be modified to collect incoming payloads until one
of two events has occurred:
(1) a specific number of octets, MAX-SF-LEN, has arrived at
the multiplexer, or
(2) a timer, called T, has expired.
<span class="grey">Thompson, et al. Best Current Practice [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 2005</span>
When either condition is satisfied, the multiplexed PPP payload is
transmitted.
The purpose of MAX-SF-LEN is to ensure that a PPPMUX payload does not
exceed the MTU size of any of the possible physical links that the
tunnel can be associated with. The value of MAX-SF-LEN should be
less than or equal to the minimum of MRU-2 (maximum size of length
field) and 16,383 (14 bits) for all possible physical interfaces that
the tunnel may be associated with.
The timer T provides an upper delay bound for tunnel interfaces.
Timer T is reset whenever a multiplexed payload is sent to the next
encapsulation layer. The behavior of this timer is similar to AAL2's
Timer_CU described in [<a href="#ref-I.363.2" title=""B-ISDN ATM Adaptation layer specification: Type 2 AAL"">I.363.2</a>]. Each PPPMUX transmitter should have
its own Timer T.
The optimal values for T will vary depending upon the rate at which
payloads are expected to arrive at the multiplexer and the delay
budget for the multiplexing function. For voice applications, the
value of T would typically be 5-10 milliseconds.
<span class="h4"><a class="selflink" id="section-2.3.2" href="#section-2.3.2">2.3.2</a>. Tunneling Inefficiencies</span>
To get reasonable bandwidth efficiency using multiplexing within an
L2TP tunnel, multiple RTP streams should be active between the source
and destination of an L2TP tunnel.
If the source and destination of the L2TP tunnel are the same as the
source and destination of the ECRTP sessions, then the source and
destination must have multiple active RTP streams to get any benefit
from multiplexing.
Because of this limitation, TCRTP is mostly useful for applications
where many RTP sessions run between a pair of RTP endpoints. The
number of simultaneous RTP sessions required to reduce the header
overhead to the desired level depends on the size of the L2TP header.
A smaller L2TP header will result in fewer simultaneous RTP sessions
being required to produce bandwidth efficiencies similar to CRTP.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Tunneling: L2TP</span>
L2TP tunnels should be used to tunnel the ECRTP payloads end to end.
L2TP includes methods for tunneling messages used in PPP session
establishment, such as NCP. This allows [<a href="#ref-IPCP-HC" title=""IP Header Compression over PPP"">IPCP-HC</a>] to negotiate ECRTP
compression/decompression parameters.
<span class="grey">Thompson, et al. Best Current Practice [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 2005</span>
<span class="h4"><a class="selflink" id="section-2.4.1" href="#section-2.4.1">2.4.1</a>. Tunneling and DiffServ</span>
RTP streams may be marked with Expedited Forwarding (EF) bits, as
described in [<a href="#ref-EF-PHB" title=""An Expedited Forwarding PHB (Per-Hop Behavior)"">EF-PHB</a>]. When such a packet is tunneled, the tunnel
header must also be marked for the same EF bits, as required by
[<a href="#ref-EF-PHB" title=""An Expedited Forwarding PHB (Per-Hop Behavior)"">EF-PHB</a>]. It is important to not mix EF and non-EF traffic in the
same EF-marked multiplexed tunnel.
<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>. Encapsulation Formats</span>
The packet format for an RTP packet, compressed with RTP header
compression as defined in ECRTP, is:
+---------+---------+-------------+-----------------------+
| | MSTI | | |
| Context | | UDP | |
| ID | Link | Checksum | RTP Data |
| | Sequence| | |
| (1-2) | (1) | (0-2) | |
+---------+---------+-------------+-----------------------+
The packet format of a multiplexed PPP packet as defined by [<a href="#ref-PPP-MUX" title=""PPP Multiplexing"">PPP-MUX</a>]
is:
+-------+---+------+-------+-----+ +---+------+-------+-----+
| Mux |P L| | | | |P L| | | |
| PPP |F X|Len1 | PPP | | |F X|LenN | PPP | |
| Prot. |F T| | Prot. |Info1| ~ |F T| | Prot. |InfoN|
| Field | | Field1| | | |FieldN | |
| (1) |1-2 octets| (0-2) | | |1-2 octets| (0-2) | |
+-------+----------+-------+-----+ +----------+-------+-----+
The combined format used for TCRTP with a single payload is all of
the above packets concatenated. Here is an example with one payload:
+------+-------+----------+-------+-------+-----+-------+----+
| IP | Mux |P L| | | | MSTI| | |
|header| PPP |F X|Len1 | PPP |Context| | UDP |RTP |
| (20) | Proto |F T| | Proto | ID | Link| Cksum |Data|
| | Field | | Field1| | Seq | | |
| | (1) |1-2 octets| (0-2) | (1-2) | (1) | (0-2) | |
+------+-------+----------+-------+-------+-----+-------+----+
|<------------- IP payload ------------------------->|
|<----- PPPmux payload --------------------->|
If the tunnel contains multiplexed traffic, multiple "PPPMux
payload"s are transmitted in one IP packet.
<span class="grey">Thompson, et al. Best Current Practice [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 2005</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Bandwidth Efficiency</span>
The expected bandwidth efficiency attainable with TCRTP depends upon
a number of factors. These factors include multiplexing gain,
expected packet loss rate across the network, and rates of change of
specific fields within the IP and RTP headers. This section also
describes how TCRTP significantly enhances bandwidth efficiency for
voice over IP over ATM.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Multiplexing Gains</span>
Multiplexing reduces the overhead associated with the layer 2 and
tunnel headers. Increasing the number of CRTP payloads combined into
one multiplexed PPP payload increases multiplexing gain. As traffic
increases within a tunnel, more payloads are combined in one
multiplexed payload. This will increase multiplexing gain.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Packet Loss Rate</span>
Loss of a multiplexed packet causes packet loss for all of the flows
within the multiplexed packet.
When the expected loss rate in a tunnel is relatively low (less than
perhaps 5%), the robust operation (described in [<a href="#ref-ECRTP" title=""Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering"">ECRTP</a>]) should be
sufficient to ensure delivery of state changes. This robust
operation is characterized by a parameter N, which means that the
probability of more than N adjacent packets getting lost on the
tunnel is small.
A value of N=1 will protect against the loss of a single packet
within a compressed session, at the expense of bandwidth. A value of
N=2 will protect against the loss of two packets in a row within a
compressed session and so on. Higher values of N have higher
bandwidth penalties.
The optimal value of N will depend on the loss rate in the tunnel.
If the loss rate is high (above perhaps 5%), more advanced techniques
must be employed. Those techniques are beyond the scope of this
document.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Bandwidth Calculation for Voice and Video Applications</span>
The following formula uses the factors described above to model per-
flow bandwidth usage for both voice and video applications. These
variables are defined:
<span class="grey">Thompson, et al. Best Current Practice [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 2005</span>
SOV-TCRTP, unit: octet. Per-payload overhead of ECRTP and the
multiplexed PPP header. This value does not include
additional overhead for updating IP ID or the RTP Time Stamp
fields (see [<a href="#ref-ECRTP" title=""Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering"">ECRTP</a>] for details on IP ID). The value assumes
the use of the COMPRESSED_RTP payload type. It consists of 1
octet for the ECRTP context ID, 1 octet for COMPRESSED_RTP
flags, 2 octets for the UDP checksum, 1 octet for PPP protocol
ID, and 1 octet for the multiplexed PPP length field. The
total is 6 octets.
POV-TCRTP, unit: octet. Per-packet overhead of tunneled ECRTP. This
is the overhead for the tunnel header and the multiplexed PPP
payload type. This value is 20 octets for the IP header, 4
octets for the L2TPv3 header and 1 octet for the multiplexed
PPP protocol ID. The total is 25 octets.
TRANSMIT-LENGTH, unit: milliseconds. The average duration of a
transmission (such as a talk spurt for voice streams).
SOV-TSTAMP, unit: octet. Additional per-payload overhead of the
COMPRESSED_UDP header that includes the absolute time stamp
field. This value includes 1 octet for the extra flags field
in the COMPRESSED_UDP header and 4 octets for the absolute
time stamp, for a total of 5 octets.
SOV-IPID, unit: octet. Additional per-payload overhead of the
COMPRESSED_UDP header that includes the absolute IPID field.
This value includes 2 octets for the absolute IPID. This
value also includes 1 octet for the extra flags field in the
COMPRESSED_UDP header. The total is 3 octets.
IPID-RATIO, unit: integer values 0 or 1. Indicates the frequency at
which IPID will be updated by the compressor. If IPID is
changing randomly and thus always needs to be updated, then
the value is 1. If IPID is changing by a fixed constant
amount between payloads of a flow, then IPID-RATIO will be 0.
The value of this variable does not consider the IPID value at
the beginning of a voice or video transmission, as that is
considered by the variable TRANSMIT-LENGTH. The
implementation of the sending IP stack and RTP application
controls this behavior. See <a href="#section-1.1">Section 1.1</a>.
NREP, unit: integer (usually a number between 1 and 3). This is the
number of times an update field will be repeated in ECRTP
headers to increase the delivery rate between the compressor
and decompressor. For this example, we will assume NREP=2.
PAYLOAD-SIZE, unit: octets. The size of the RTP payload in octets.
<span class="grey">Thompson, et al. Best Current Practice [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 2005</span>
MUX-SIZE, unit: count. The number of PPP payloads multiplexed into
one multiplexed PPP payload.
SAMPLE-PERIOD, unit: milliseconds. The average delay between
transmissions of voice or video payloads for each flow in the
multiplex. For example, in voice applications the value of
this variable would be 10ms if all calls have a 10ms sample
period.
The formula is:
SOV-TOTAL = SOV-TCRTP + SOV-TSTAMP * (NREP * SAMPLE-PERIOD /
TRANSMIT-LENGTH) + SOV-IPID * IPID-RATIO
BANDWIDTH = ((PAYLOAD-SIZE + SOV-TOTAL + (POV-TCRTP / MUX-SIZE)) *
8) / SAMPLE-PERIOD)
The results are:
BANDWIDTH, unit: kilobits per second. The average amount of
bandwidth used per voice or video flow.
SOV-TOTAL = The total amount of per-payload overhead associated
with tunneled ECRTP. It includes the per-payload
overhead of ECRTP and PPP, timestamp update overhead,
and IPID update overhead.
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. Voice Bandwidth Calculation Example</span>
To create an example for a voice application using the above
formulas, we will assume the following usage scenario. Compressed
voice streams using G.729 compression with a 20 millisecond
packetization period. In this scenario, VAD is enabled and the
average talk spurt length is 1500 milliseconds. The IPID field is
changing randomly between payloads of streams. There is enough
traffic in the tunnel to allow 3 multiplexed payloads. The following
values apply:
SAMPLE-PERIOD = 20 milliseconds
TRANSMIT-LENGTH = 1500 milliseconds
IPID-RATIO = 1
PAYLOAD-SIZE = 20 octets
MUX-SIZE = 3
For this example, per call bandwidth is 16.4 kbits/sec. Classical
CRTP over a single HDLC link using the same factors as above yields
12.4 kbits/sec.
<span class="grey">Thompson, et al. Best Current Practice [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 2005</span>
The effect of IPID can have a large effect on per call bandwidth. If
the above example is recalculated using an IPID-RATIO of 0, then the
per call bandwidth is reduced to 13.8 kbits/sec. Classical CRTP over
a single HDLC link, using these same factors, yields 11.2 kbits/call.
<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>. Voice Bandwidth Comparison Table</span>
The bandwidth values are as follows when using 5 simultaneous calls,
no voice activity detection (VAD), G.729 with 20ms packetization
interval, and not considering RTCP overhead:
Normal VoIP over PPP: 124 kbps
with classical CRTP on a link: 50 kbps (savings: 59%)
with TCRTP over PPP: 62 kbps (savings: 50%)
with TCRTP over AAL5: 85 kbps (savings: 31%)
<span class="h4"><a class="selflink" id="section-3.3.3" href="#section-3.3.3">3.3.3</a>. Video Bandwidth Calculation Example</span>
Since TCRTP can be used to save bandwidth on any type of RTP
encapsulated flow, it can be used to save bandwidth for video
applications. This section documents an example of TCRTP-based
bandwidth savings for MPEG-2 encoded video.
To create an example for a video application using the above
formulas, we will assume the following usage scenario. RTP
encapsulation of MPEG System and Transport Streams is performed as
described in <a href="./rfc2250">RFC 2250</a>. Frames for MPEG-2 encoded video are sent
continuously, so the TRANSMIT-LENGTH variable in the bandwidth
formula is essentially infinite. The IPID field is changing randomly
between payloads of streams. There is enough traffic in the tunnel
to allow 3 multiplexed payloads. The following values apply:
SAMPLE-PERIOD = 2.8 milliseconds
TRANSMIT-LENGTH = infinite
IPID-RATIO = 1
PAYLOAD-SIZE = 1316 octets
MUX-SIZE = 3
For this example, per flow bandwidth is 3.8 Mbits/sec. MPEG video
with no header compression, using the same factors as above, yields
3.9 Mbits/sec. While TCRTP does provide some bandwidth savings for
video, the ratio of transmission headers to payload is so small that
the bandwidth savings are insignificant.
<span class="grey">Thompson, et al. Best Current Practice [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 2005</span>
<span class="h4"><a class="selflink" id="section-3.3.4" href="#section-3.3.4">3.3.4</a>. TCRTP over ATM</span>
IP transport over AAL5 causes a quantizing effect on bandwidth
utilization due to the packets always being multiples of ATM cells.
For example, the payload size for G.729 using 10 millisecond
packetization intervals is 10 octets. This is much smaller than the
payload size of an ATM cell (48 octets). When classical CRTP [<a href="#ref-CRTP" title=""Compressing IP/UDP/RTP Headers for Low-Speed Serial Links"">CRTP</a>]
is used on a link-by-link basis, the IP overhead to payload ratio is
quite good. However, AAL5 encapsulation and its cell padding always
force the minimum payload size to be one ATM cell, which results in
poor bandwidth utilization.
Instead of wasting this padding, the multiplexing of TCRTP allows
this previously wasted space in the ATM cell to contain useful data.
This is one of the main reasons why multiplexing has such a large
effect on bandwidth utilization with Voice over IP over ATM.
This multiplexing efficiency of TCRTP is similar to AAL2 sub-cell
multiplexing described in [<a href="#ref-I.363.2" title=""B-ISDN ATM Adaptation layer specification: Type 2 AAL"">I.363.2</a>]. Unlike AAL2 sub-cell
multiplexing, however, TCRTP's multiplexing efficiency isn't limited
to only ATM networks.
<span class="h4"><a class="selflink" id="section-3.3.5" href="#section-3.3.5">3.3.5</a>. TCRTP over Non-ATM Networks</span>
When TCRTP is used with other layer 2 encapsulations that do not have
a minimum PDU size, the benefit of multiplexing is not as great.
Depending upon the exact overhead of the layer 2 encapsulation, the
benefit of multiplexing might be slightly better or worse than link-
by-link CRTP header compression. The per-payload overhead of CRTP
tunneling is either 4 or 6 octets. If classical CRTP plus layer 2
overhead is greater than this amount, TCRTP multiplexing will consume
less bandwidth than classical CRTP when the outer IP header is
amortized over a large number of payloads.
The payload breakeven point can be determined by the following
formula:
POV-L2 * MUX-SIZE >= POV-L2 + POV-TUNNEL + POV-PPPMUX + SOV-PPPMUX
* MUX-SIZE
Where:
POV-L2, unit: octet. Layer 2 packet overhead: 5 octets for HDLC
encapsulation
<span class="grey">Thompson, et al. Best Current Practice [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 2005</span>
POV-TUNNEL, unit: octet. Packet overhead due to tunneling: 24
octets IP header and L2TPv3 header
POV-PPPMUX, unit: octet. Packet overhead for the multiplexed PPP
protocol ID: 1 octet
SOV-PPPMUX, unit: octet. Per-payload overhead of PPPMUX, which is
comprised of the payload length field and the ECRTP protocol
ID. The value of SOV-PPPMUX is typically 1, 2, or 3.
If using HDLC as the layer 2 protocol, the breakeven point (using the
above formula) is when MUX-SIZE = 7. Thus 7 voice or video flows
need to be multiplexed to make TCRTP as bandwidth-efficient as link-
by-link CRTP compression.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Example Implementation of TCRTP</span>
This section describes an example implementation of TCRTP.
Implementations of TCRTP may be done in many ways as long as the
requirements of the associated RFCs are met.
Here is the path an RTP packet takes in this implementation:
<span class="grey">Thompson, et al. Best Current Practice [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 2005</span>
+-------------------------------+ ^
| Application | |
+-------------------------------+ |
| RTP | |
+-------------------------------+ Application and
| UDP | IP stack
+-------------------------------+ |
| IP | |
+-------------------------------+ V
|
| IP forwarding
|
+-------------------------------+ ^
| ECRTP | |
+-------------------------------+ |
| PPPMUX | |
+-------------------------------+ Tunnel
| PPP | Interface
+-------------------------------+ |
| L2TP | |
+-------------------------------+ |
| IP | |
+-------------------------------+ V
|
| IP forwarding
|
+-------------------------------+ ^
| Layer 2 | |
+-------------------------------+ Physical
| Physical | Interface
+-------------------------------+ V
A protocol stack is configured to create an L2TP tunnel interface to
a destination host. The tunnel is configured to negotiate the PPP
connection (using NCP IPCP) with ECRTP header compression and PPPMUX.
IP forwarding is configured to route RTP packets to this tunnel. The
destination UDP port number could distinguish RTP packets from non-
RTP packets.
The transmitting application gathers the RTP data from one source,
and formats an RTP packet. Lower level application layers add UDP
and IP headers to form a complete IP packet.
The RTP packets are routed to the tunnel interface where headers are
compressed, payloads are multiplexed, and then the packets are
tunneled to the destination host.
<span class="grey">Thompson, et al. Best Current Practice [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 2005</span>
The operation of the receiving node is the same as the transmitting
node in reverse.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Suggested PPP and L2TP Negotiation for TCRTP</span>
This section describes the necessary PPP and LT2P negotiations
necessary for establishing a PPP connection and L2TP tunnel with L2TP
header compression. The negotiation is between two peers: Peer1 and
Peer2.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. PPP Negotiation TCRTP</span>
The Point-to-Point Protocol is described in [<a href="#ref-PPP" title=""The Point-to-Point Protocol (PPP)"">PPP</a>].
<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>. LCP Negotiation</span>
Link Control Processing (LCP) is described in [<a href="#ref-PPP" title=""The Point-to-Point Protocol (PPP)"">PPP</a>].
<span class="h5"><a class="selflink" id="section-4.2.1.1" href="#section-4.2.1.1">4.2.1.1</a>. Link Establishment</span>
Peer1 Peer2
----- -----
Configure-Request (no options) ->
<- Configure-Ack
<- Configure-Request (no options)
Configure-Ack ->
<span class="h5"><a class="selflink" id="section-4.2.1.2" href="#section-4.2.1.2">4.2.1.2</a>. Link Tear Down</span>
Terminate-Request ->
<- Terminate-Ack
<span class="grey">Thompson, et al. Best Current Practice [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 2005</span>
<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>. IPCP Negotiation</span>
The protocol exchange here is described in [<a href="#ref-IPHCOMP" title=""IP Header Compression"">IPHCOMP</a>], [<a href="#ref-PPP" title=""The Point-to-Point Protocol (PPP)"">PPP</a>], and
[<a href="#ref-ECRTP" title=""Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering"">ECRTP</a>].
Peer1 Peer2
----- -----
Configure-Request ->
Options:
IP-Compression-Protocol
Use protocol 0x61
and sub-parameters
as described in
[<a href="#ref-IPCP-HC" title=""IP Header Compression over PPP"">IPCP-HC</a>] and [<a href="#ref-ECRTP" title=""Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering"">ECRTP</a>]
<- Configure-Ack
<- Configure-Request
Options:
IP-Compression-Protocol
Use protocol 0x61
and sub-parameters
as described in
[<a href="#ref-IPCP-HC" title=""IP Header Compression over PPP"">IPCP-HC</a>] and [<a href="#ref-ECRTP" title=""Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering"">ECRTP</a>]
Configure-Ack ->
<span class="grey">Thompson, et al. Best Current Practice [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 2005</span>
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. L2TP Negotiation</span>
L2TP is described in [<a href="#ref-L2TPv3" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">L2TPv3</a>].
<span class="h4"><a class="selflink" id="section-4.3.1" href="#section-4.3.1">4.3.1</a>. Tunnel Establishment</span>
Peer1 Peer2
----- -----
SCCRQ ->
Mandatory AVP's:
Message Type
Protocol Version
Host Name
Framing Capabilities
Assigned Tunnel ID
<- SCCRP
Mandatory AVP's:
Message Type
Protocol Version
Host Name
Framing Capabilities
Assigned Tunnel ID
SCCCN ->
Mandatory AVP's:
Message Type
<- ZLB
<span class="h4"><a class="selflink" id="section-4.3.2" href="#section-4.3.2">4.3.2</a>. Session Establishment</span>
Peer1 Peer2
----- -----
ICRQ ->
Mandatory AVP's:
Message Type
Assigned Session ID
Call Serial Number
<- ICRP
Mandatory AVP's:
Message Type
Assigned Session ID
ICCN ->
Mandatory AVP's:
Message Type
Tx (Connect Speed)
Framing Type
<- ZLB
<span class="grey">Thompson, et al. Best Current Practice [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 2005</span>
<span class="h4"><a class="selflink" id="section-4.3.3" href="#section-4.3.3">4.3.3</a>. Tunnel Tear Down</span>
Peer1 Peer2
----- -----
StopCCN ->
Mandatory AVP's:
Message Type
Assigned Tunnel ID
Result Code
<- ZLB
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
This document describes a method for combining several existing
protocols that implement compression, multiplexing, and tunneling of
RTP streams. Attacks on the component technologies of TCRTP include
attacks on RTP/RTCP headers and payloads carried within a TCRTP
session, attacks on the compressed headers, attacks on the
multiplexing layer, or attacks on the tunneling negotiation or
transport. The security issues associated individually with each of
those component technologies are addressed in their respective
specifications, [<a href="#ref-ECRTP" title=""Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering"">ECRTP</a>], [<a href="#ref-PPP-MUX" title=""PPP Multiplexing"">PPP-MUX</a>], [<a href="#ref-L2TPv3" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">L2TPv3</a>], along with the security
considerations for RTP itself [<a href="#ref-RTP" title=""RTP: A Transport Protocol for Real-Time Applications"">RTP</a>].
However, there may be additional security considerations arising from
the use of these component technologies together. For example, there
may be an increased risk of unintended misdelivery of packets from
one stream in the multiplex to another due to a protocol malfunction
or data error because the addressing information is more condensed.
This is particularly true if the tunnel is transmitted over a link-
layer protocol that allows delivery of packets containing bit errors,
in combination with a tunnel transport layer option that does not
checksum all of the payload.
The opportunity for malicious misdirection may be increased, relative
to that for a single RTP stream transported by itself, because
addressing information must be unencrypted for the header compression
and multiplexing layers to function.
The primary defense against misdelivery is to make the data unusable
to unintended recipients through cryptographic techniques. The basic
method for encryption provided in the RTP specification [<a href="#ref-RTP" title=""RTP: A Transport Protocol for Real-Time Applications"">RTP</a>] is not
suitable because it encrypts the RTP and RTCP headers along with the
payload. However, the RTP specification also allows alternative
approaches to be defined in separate profile or payload format
specifications wherein only the payload portion of the packet would
be encrypted; therefore, header compression may be applied to the
encrypted packets. One such profile, [<a href="#ref-SRTP" title=""The Secure Real-time Transport Protocol (SRTP)"">SRTP</a>], provides more
<span class="grey">Thompson, et al. Best Current Practice [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 2005</span>
sophisticated and complete methods for encryption and message
authentication than the basic approach in [<a href="#ref-RTP" title=""RTP: A Transport Protocol for Real-Time Applications"">RTP</a>]. Additional methods
may be developed in the future. Appropriate cryptographic protection
should be incorporated into all TCRTP applications.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Acknowledgements</span>
The authors would like to thank the authors of <a href="./rfc2508">RFC 2508</a>, Stephen
Casner and Van Jacobson, and the authors of <a href="./rfc2507">RFC 2507</a>, Mikael
Degermark, Bjorn Nordgren, and Stephen Pink.
The authors would also like to thank Dana Blair, Alex Tweedley, Paddy
Ruddy, Francois Le Faucheur, Tim Gleeson, Matt Madison, Hussein
Salama, Mallik Tatipamula, Mike Thomas, Mark Townsley, Andrew
Valencia, Herb Wildfeuer, J. Martin Borden, John Geevarghese, and
Shoou Yiu.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-PPP-MUX">PPP-MUX</a>] Pazhyannur, R., Ali, I., and C. Fox, "PPP Multiplexing",
<a href="./rfc3153">RFC 3153</a>, August 2001.
[<a id="ref-ECRTP">ECRTP</a>] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and
P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with
High Delay, Packet Loss and Reordering", <a href="./rfc3545">RFC 3545</a>, July
2003.
[<a id="ref-CRTP">CRTP</a>] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers
for Low-Speed Serial Links", <a href="./rfc2508">RFC 2508</a>, February 1999.
[<a id="ref-IPHCOMP">IPHCOMP</a>] Degermark, M., Nordgren, B., and S. Pink, "IP Header
Compression", <a href="./rfc2507">RFC 2507</a>, February 1999.
[<a id="ref-IPCP-HC">IPCP-HC</a>] Engan, M., Casner, S., Bormann, C., and T. Koren, "IP
Header Compression over PPP", <a href="./rfc3544">RFC 3544</a>, July 2003.
[<a id="ref-RTP">RTP</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.
[<a id="ref-L2TPv3">L2TPv3</a>] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", <a href="./rfc3931">RFC 3931</a>, March 2005.
[<a id="ref-I.363.2">I.363.2</a>] ITU-T, "B-ISDN ATM Adaptation layer specification: Type 2
AAL", I.363.2, September 1997.
<span class="grey">Thompson, et al. Best Current Practice [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 2005</span>
[<a id="ref-EF-PHB">EF-PHB</a>] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis,
"An Expedited Forwarding PHB (Per-Hop Behavior)", <a href="./rfc3246">RFC 3246</a>,
March 2002.
[<a id="ref-PPP">PPP</a>] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
<a href="./rfc1661">RFC 1661</a>, July 1994.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-SRTP">SRTP</a>] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
<a href="./rfc3711">RFC 3711</a>, March 2004.
[<a id="ref-REORDER">REORDER</a>] G. Pelletier, L. Jonsson, K. Sandlund, "RObust Header
Compression (ROHC): ROHC over Channels that can Reorder
Packets", Work in Progress, June 2004.
[<a id="ref-ROHC">ROHC</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.
<span class="grey">Thompson, et al. Best Current Practice [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 2005</span>
Authors' Addresses
Bruce Thompson
170 West Tasman Drive
San Jose, CA 95134-1706
United States of America
Phone: +1 408 527 0446
EMail: brucet@cisco.com
Tmima Koren
170 West Tasman Drive
San Jose, CA 95134-1706
United States of America
Phone: +1 408 527 6169
EMail: tmima@cisco.com
Dan Wing
170 West Tasman Drive
San Jose, CA 95134-1706
United States of America
EMail: dwing@cisco.com
<span class="grey">Thompson, et al. Best Current Practice [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc4170">RFC 4170</a> Tunneling Multiplexed Compressed RTP November 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.
Thompson, et al. Best Current Practice [Page 24]
</pre>
|
