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
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
3027
|
Networking Working Group M. Ramadas
Request for Comments: 5326 ISTRAC, ISRO
Category: Experimental S. Burleigh
NASA/Jet Propulsion Laboratory
S. Farrell
Trinity College Dublin
September 2008
Licklider Transmission Protocol - Specification
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
IESG Note
This RFC is not a candidate for any level of Internet Standard. It
represents the consensus of the Delay Tolerant Networking (DTN)
Research Group of the Internet Research Task Force (IRTF). It may be
considered for standardization by the IETF in the future, but the
IETF disclaims any knowledge of the fitness of this RFC for any
purpose and in particular notes that the decision to publish is not
based on IETF review for such things as security, congestion control,
or inappropriate interaction with deployed protocols. See RFC 3932
for more information.
Abstract
This document describes the Licklider Transmission Protocol (LTP),
designed to provide retransmission-based reliability over links
characterized by extremely long message round-trip times (RTTs)
and/or frequent interruptions in connectivity. Since communication
across interplanetary space is the most prominent example of this
sort of environment, LTP is principally aimed at supporting "long-
haul" reliable transmission in interplanetary space, but it has
applications in other environments as well.
This document is a product of the Delay Tolerant Networking Research
Group and has been reviewed by that group. No objections to its
publication as an RFC were raised.
Ramadas, et al. Experimental [Page 1]
^L
RFC 5326 LTP - Specification September 2008
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Segment Structure ...............................................9
3.1. Segment Header ............................................10
3.1.1. Segment Type Flags .................................11
3.1.2. Segment Type Codes .................................13
3.1.3. Segment Class Masks ................................14
3.1.4. Extensions Field ...................................14
3.2. Segment Content ...........................................16
3.2.1. Data Segment (DS) ..................................16
3.2.2. Report Segment (RS) ................................17
3.2.3. Report Acknowledgment Segment ......................19
3.2.4. Session Management Segments ........................20
3.3. Segment Trailer ...........................................20
4. Requests from Client Service ...................................20
4.1. Transmission Request ......................................21
4.2. Cancellation Request ......................................22
5. Requirements from the Operating Environment ....................23
6. Internal Procedures ............................................24
6.1. Start Transmission ........................................25
6.2. Start Checkpoint Timer ....................................25
6.3. Start RS Timer ............................................25
6.4. Stop Transmission .........................................25
6.5. Suspend Timers ............................................26
6.6. Resume Timers .............................................26
6.7. Retransmit Checkpoint .....................................27
6.8. Retransmit RS .............................................27
6.9. Signify Red-Part Reception ................................28
6.10. Signify Green-Part Segment Arrival .......................28
6.11. Send Reception Report ....................................28
6.12. Signify Transmission Completion ..........................30
6.13. Retransmit Data ..........................................30
6.14. Stop RS Timer ............................................31
6.15. Start Cancel Timer .......................................32
6.16. Retransmit Cancellation Segment ..........................32
6.17. Acknowledge Cancellation .................................32
6.18. Stop Cancel Timer ........................................33
6.19. Cancel Session ...........................................33
6.20. Close Session ............................................33
6.21. Handle Miscolored Segment ................................33
6.22. Handling System Error Conditions .........................34
7. Notices to Client Service ......................................35
7.1. Session Start .............................................35
7.2. Green-Part Segment Arrival ................................36
7.3. Red-Part Reception ........................................36
7.4. Transmission-Session Completion ...........................36
Ramadas, et al. Experimental [Page 2]
^L
RFC 5326 LTP - Specification September 2008
7.5. Transmission-Session Cancellation .........................37
7.6. Reception-Session Cancellation ............................37
7.7. Initial-Transmission Completion ...........................37
8. State Transition Diagrams ......................................38
8.1. Sender ....................................................39
8.2. Receiver ..................................................44
9. Security Considerations ........................................48
9.1. Denial of Service Considerations ..........................48
9.2. Replay Handling ...........................................49
9.3. Implementation Considerations .............................50
10. IANA Considerations ...........................................51
10.1. UDP Port Number for LTP ..................................51
10.2. LTP Extension Tag Registry ...............................51
11. Acknowledgments ...............................................51
12. References ....................................................52
12.1. Normative References .....................................52
12.2. Informative References ...................................52
1. Introduction
This document serves as the main protocol specification of LTP and is
part of a series of documents describing LTP. Other documents in
this series include the motivation document [LTPMTV] and the protocol
extensions document [LTPEXT]. We strongly recommend reading the
protocol motivation document before reading this document, to
establish sufficient background and motivation for the specification.
LTP does Automatic Repeat reQuest (ARQ) of data transmissions by
soliciting selective-acknowledgment reception reports. It is
stateful, and has no negotiation or handshakes.
In an Interplanetary Internet setting deploying the Bundle Protocol
that is being developed by the Delay Tolerant Networking Research
Group, LTP is intended to serve as a reliable "convergence layer"
protocol operating in pairwise fashion between adjacent
Interplanetary Internet nodes that are in direct radio frequency (RF)
communication. In that operational scenario, and potentially in some
other deployments of the Bundle Protocol, LTP runs directly over a
data-link layer protocol; when this is the case, forward error
correction coding and/or checksum mechanisms in the underlying data-
link layer protocol must ensure the integrity of the data passed
between the communicating entities.
Since no mechanisms for flow control or congestion control are
included in the design of LTP, this protocol is not intended or
appropriate for ubiquitous deployment in the global Internet.
Ramadas, et al. Experimental [Page 3]
^L
RFC 5326 LTP - Specification September 2008
When LTP is run over UDP, it must only be used for software
development or in private local area networks. When LTP is not run
over UDP, it must be run directly over a protocol (nominally a link-
layer protocol) that meets the requirements specified in Section 5.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [B97].
2. Terminology
(1) Engine ID
A number that uniquely identifies a given LTP engine, within some
closed set of communicating LTP engines. Note that when LTP is
operating underneath the Delay-Tolerant Networking (DTN) [DTN] Bundle
Protocol [BP], the convergence layer adapter mediating the two will
be responsible for translating between DTN endpoint IDs and LTP
engine IDs in an implementation-specific manner.
(2) Block
An array of contiguous octets of application data handed down by the
upper layer protocol (typically Bundle Protocol) to be transmitted
from one LTP client service instance to another.
Any subset of a block comprising contiguous octets beginning at the
start of the block is termed a "block prefix", and any such subset of
the block ending with the end of the block is termed a "block
suffix".
(3) Red-Part
The block prefix that is to be transmitted reliably, i.e., subject to
acknowledgment and retransmission.
(4) Green-Part
The block suffix that is to be transmitted unreliably, i.e., not
subject to acknowledgments or retransmissions. If present, the
green-part of a block begins at the octet following the end of the
red-part.
(5) Session
A thread of LTP protocol activity conducted between two peer engines
for the purpose of transmitting a block. Data flow in a session is
unidirectional: data traffic flows from the sending peer to the
Ramadas, et al. Experimental [Page 4]
^L
RFC 5326 LTP - Specification September 2008
receiving peer, while data-acknowledgment traffic flows from the
receiving peer to the sending peer.
(6) Sender
The data sending peer of a session.
(7) Receiver
The data receiving peer of a session.
(8) Client Service Instance
A software entity, such as an application or a higher-layer protocol
implementation, that is using LTP to transfer data.
(9) Segment
The unit of LTP data transmission activity. It is the data structure
transmitted from one LTP engine to another in the course of a
session. Each LTP segment is of one of the following types: data
segment, report segment, report-acknowledgment segment, cancel
segment, cancel-acknowledgment segment.
(10) Reception Claim
An assertion of reception of some number of contiguous octets of
application data (a subset of a block) characterized by: the offset
of the first received octet, and the number of contiguous octets
received (beginning at the offset).
(11) Scope
Scope identifies a subset of a block and comprises two numbers --
upper bound and lower bound.
For a data segment, lower bound is the offset of the segment's
application data from the start of the block (in octets), while upper
bound is the sum of the offset and length of the segment's
application data (in octets). For example, a segment with a block
offset of 1000 and length of 500 would have a lower bound of 1000 and
upper bound of 1500.
For a report segment, upper bound is the end of the block prefix to
which the reception claims in the report apply, while lower bound is
the end of the (smaller) interior block prefix to which the reception
claims in the report do *not* apply. That is, data at any offset
equal to or greater than the report's lower bound but less than its
Ramadas, et al. Experimental [Page 5]
^L
RFC 5326 LTP - Specification September 2008
upper bound and not designated as "received" by any of the report's
reception claims must be assumed not received, and therefore eligible
for retransmission. For example, if a report segment carried a lower
bound of 1000 and an upper bound of 5000, and the reception claims
indicated reception of data within offsets 1000-1999 and 3000-4999,
data within the block offsets 2000-2999 can be considered missing and
eligible for retransmission.
Reception reports (which may comprise multiple report segments) also
have scope, as defined in Section 6.11.
(12) End of Block (EOB)
The last data segment transmitted as part of the original
transmission of a block. This data segment also indicates that the
segment's upper bound is the total length of the block (in octets).
(13) End of Red-Part (EORP)
The segment transmitted as part of the original transmission of a
block containing the last octet of the block's red-part. This data
segment also indicates that the segment's upper bound is the length
of the block's red-part (in octets).
(14) Checkpoint
A data segment soliciting a reception report from the receiving LTP
engine. The EORP segment must be flagged as a checkpoint, as must
the last segment of any retransmission; these are "mandatory
checkpoints". All other checkpoints are "discretionary checkpoints".
(15) Reception Report
A sequence of one or more report segments reporting on all block data
reception within some scope.
(16) Synchronous Reception Report
A reception report that is issued in response to a checkpoint.
(17) Asynchronous Reception Report
A reception report that is issued in response to some implementation-
defined event other than the arrival of a checkpoint.
Ramadas, et al. Experimental [Page 6]
^L
RFC 5326 LTP - Specification September 2008
(18) Primary Reception Report
A reception report that is issued in response to some event other
than the arrival of a checkpoint segment that was itself issued in
response to a reception report. Primary reception reports include
all asynchronous reception reports and all synchronous reception
reports that are sent in response to discretionary checkpoints or to
the EORP segment for a session.
(19) Secondary Reception Report
A reception report that is issued in response to the arrival of a
checkpoint segment that was itself issued in response to a reception
report.
(20) Self-Delimiting Numeric Value (SDNV)
The design of LTP attempts to reconcile minimal consumption of
transmission bandwidth with
(a) extensibility to satisfy requirements not yet identified, and
(b) scalability across a very wide range of network sizes and
transmission payload sizes.
The SDNV encoding scheme is modeled after the Abstract Syntax
Notation One [ASN1] scheme for encoding Object Identifier values. In
a data field encoded as an SDNV, the most significant bit (MSB) of
each octet of the SDNV serves to indicate whether or not the octet is
the last octet of the SDNV. An octet with an MSB of 1 indicates that
it is either the first or a middle octet of a multi-octet SDNV; the
octet with an MSB of 0 is the last octet of the SDNV. The value
encoded in an SDNV is found by concatenating the 7 least significant
bits of each octet of the SDNV, beginning at the first octet and
ending at the last octet.
Ramadas, et al. Experimental [Page 7]
^L
RFC 5326 LTP - Specification September 2008
The following examples illustrate the encoding scheme for various
hexadecimal values.
0xABC : 1010 1011 1100
is encoded as
{100 1010 1} {0 011 1100}
- -
= 10010101 00111100
0x1234 : 0001 0010 0011 0100
= 1 0010 0011 0100
is encoded as
{10 1 0010 0} {0 011 0100}
- -
= 10100100 00110100
0x4234 : 0100 0010 0011 0100
=100 0010 0011 0100
is encoded as
{1000000 1} {1 00 0010 0} {0 011 0100}
- - -
= 10000001 10000100 00110100
0x7F : 0111 1111
=111 1111
is encoded as
{0 111 1111}
-
= 01111111
Note:
Care must be taken to make sure that the value to be encoded is
padded with zeroes at the most significant bit end (NOT at the least
significant bit end) to make its bitwise length a multiple of 7
before encoding.
While there is no theoretical limit on the size of an SDNV field, we
note that the overhead of the SDNV scheme is 1:7, i.e., 1 bit of
overhead for every 7 bits of actual data to be encoded. Thus, a
Ramadas, et al. Experimental [Page 8]
^L
RFC 5326 LTP - Specification September 2008
7-octet value (a 56-bit quantity with no leading zeroes) would be
encoded in an 8-octet SDNV; an 8-octet value (a 64-bit quantity with
no leading zeroes) would be encoded in a 10-octet SDNV. In general,
an N-bit quantity with no leading zeroes would be encoded in a
ceil(N/7) octet SDNV, where ceil is the integer ceiling function.
Clearly, for fields that typically carry larger values such as RSA
public keys, the SDNV overhead could become unacceptable. Hence,
when adopting the SDNV scheme for other purposes related to this
document, such as any protocol extensions, we RECOMMEND that if the
typical data field value is expected to be larger than 8 octets, then
the data field should be specified as a {LENGTH, VALUE} tuple, with
the LENGTH parameter encoded as an SDNV followed by LENGTH octets
housing the VALUE of the data field.
We also note that SDNV is clearly not the best way to represent every
numeric value. When the maximum possible value of a number is known
without question, the cost of additional bits may not be justified.
For example, an SDNV is a poor way to represent an integer whose
value typically falls in the range 128 to 255. In general, though,
we believe that the SDNV representation of various protocol data
fields in LTP segments yields the smallest segment sizes without
sacrificing scalability.
3. Segment Structure
Each LTP segment comprises
(a) a "header" in the format defined below.
(b) zero or more octets of "content".
(c) zero or more octets of "trailer" as indicated by information
in the "Extensions field" of the header.
LTP segments are of four general types depending on the nature of the
content carried:
Data segments flow from the sender to the receiver and carry
client service (application) data.
A report segment flows from the receiver to the sender and carries
data reception claims together with the upper and lower bounds of
the block scope to which the claims pertain.
A report-acknowledgment segment flows from the sender to the
receiver and acknowledges reception of a report segment. It
carries the serial number of the report being acknowledged.
Ramadas, et al. Experimental [Page 9]
^L
RFC 5326 LTP - Specification September 2008
Session management segments may be generated by both the sender
and the receiver and are of two general sub-types: cancellation
and cancellation-acknowledgment. A cancellation segment initiates
session cancellation procedures at the peer and carries a single
byte reason-code to indicate the reason for session cancellation.
Cancellation-acknowledgment segments merely acknowledge reception
of a cancellation segment and have no content.
The overall segment structure is illustrated below:
Bit 0 1 2 3 4 5 6 7
^ +-----+-----+-----+-----+-----+-----+-----+-----+
| | Version number | Segment Type Flags | Control
| +-----------------------+-----------------------+ -byte
| | |
| / Session ID \
| \ /
Header +-----------------------+-----------------------+
| | Header Extension Cnt. | Trailer Extension Cnt.| Extensions
| +-----------------------+-----------------------+
| | |
| / Header Extensions \
| \ /
V +-----------------------------------------------+
| |
| |
| |
| Segment Content |
/ \
\ /
| |
| |
| |
^ +-----------------------------------------------+
| | |
Trailer / Trailer Extensions \
| \ /
V +-----------------------------------------------+
3.1. Segment Header
An LTP segment header comprises three data items: a single-octet
control byte, the session ID, and the Extensions field.
Control byte comprises the following:
Version number (4 bits): MUST be set to the binary value 0000 for
this version of the protocol.
Ramadas, et al. Experimental [Page 10]
^L
RFC 5326 LTP - Specification September 2008
Segment type flags (4 bits): described in Section 3.1.1.
Session ID uniquely identifies, among all transmissions between the
sender and receiver, the session of which the segment is one token.
It comprises the following:
Session originator (SDNV): the engine ID of the sender.
Session number (SDNV): typically a random number (for anti-DoS
reasons), generated by the sender.
The format and resolution of session number are matters that are
private to the LTP sender; the only requirement imposed by LTP is
that every session initiated by an LTP engine MUST be uniquely
identified by the session ID.
The Extensions field is described in Section 3.1.4.
3.1.1. Segment Type Flags
The last 4 bits of the control byte in the segment header are flags
that indicate the nature of the segment. In order (most significant
bit first), these flags are CTRL, EXC, Flag 1, and Flag 0.
A value of 0 in the CTRL (Control) flag identifies the segment as a
data segment, while a value of 1 identifies it as a control segment.
A data segment with the EXC (Exception) flag set to 0 is a red-part
segment; a data segment with EXC set to 1 is a green-part segment.
For a control segment, having the EXC flag set to 1 indicates that
the segment pertains to session cancellation activity. Any data
segment (whether red-part or green-part) with both Flag 1 and Flag 0
set to 1 indicates EOB. Any data segment (whether red-part or
green-part) with both Flag 1 and Flag 0 set to 0 indicates data
without any additional protocol significance. Any red-part data
segment with either flag bit non-zero is a checkpoint. Any red-part
data segment with Flag 1 set to 1 indicates the end of red-part.
Ramadas, et al. Experimental [Page 11]
^L
RFC 5326 LTP - Specification September 2008
Put another way:
if (CTRL flag = 0)
segment is a data segment if (EXC flag = 0)
segment contains only red-part data if (Flag 1 = 1)
segment is a checkpoint segment is the last segment in the
red part of the block if (Flag 0 = 1)
segment is the last segment in the block
else // segment is not end of red-part
if (Flag 0 = 1)
segment is a checkpoint
else
segment contains only green-part data if (Flag 1 = 1)
if (Flag 0 = 1)
segment is the last segment in the block
else
segment is a control segment if (EXC flag = 0)
segment pertains to report activity if (flag 0 = 0)
segment is a report segment
else
segment is an acknowledgment of a report segment
else
segment pertains to session cancellation activity if (Flag 1 =
0)
segment pertains to cancellation by block sender if (Flag 0
= 1)
segment is a cancellation by sender
else
segment is an acknowledgment of a cancellation by sender
else
segment pertains to cancellation by block receiver if (Flag
0 = 1)
segment is a cancellation by receiver
else
segment is an acknowledgment of a cancellation by
receiver
Ramadas, et al. Experimental [Page 12]
^L
RFC 5326 LTP - Specification September 2008
3.1.2. Segment Type Codes
Combinations of the settings of the segment type flags CTRL, EXC,
Flag 1, and Flag 0 constitute segment type codes, which serve as
concise representations of detailed segment nature.
CTRL EXC Flag 1 Flag 0 Code Nature of segment
---- --- ------ ------ ---- ---------------------------------------
0 0 0 0 0 Red data, NOT {Checkpoint, EORP or EOB}
0 0 0 1 1 Red data, Checkpoint, NOT {EORP or EOB}
0 0 1 0 2 Red data, Checkpoint, EORP, NOT EOB
0 0 1 1 3 Red data, Checkpoint, EORP, EOB
0 1 0 0 4 Green data, NOT EOB
0 1 0 1 5 Green data, undefined
0 1 1 0 6 Green data, undefined
0 1 1 1 7 Green data, EOB
1 0 0 0 8 Report segment
1 0 0 1 9 Report-acknowledgment segment
1 0 1 0 10 Control segment, undefined
1 0 1 1 11 Control segment, undefined
1 1 0 0 12 Cancel segment from block sender
1 1 0 1 13 Cancel-acknowledgment segment
to block sender
1 1 1 0 14 Cancel segment from block receiver
1 1 1 1 15 Cancel-acknowledgment segment
to block receiver
Ramadas, et al. Experimental [Page 13]
^L
RFC 5326 LTP - Specification September 2008
3.1.3. Segment Class Masks
For the purposes of this specification, some bit patterns in the
segment type flags field correspond to "segment classes" that are
designated by mnemonics. The mnemonics are intended to evoke the
characteristics shared by all types of segments characterized by
these flag bit patterns.
CTRL EXC Flag 1 Flag 0 Mnemonic Description
---- --- ------ ------ -------- ---------------------------
0 0 - 1
-- or --
0 0 1 - CP Checkpoint
0 0 1 - EORP End of red-part;
red-part size = offset + length
0 - 1 1 EOB End of block;
block size = offset + length
1 0 0 0 RS Report segment;
carries reception claims
1 0 0 1 RA Report-acknowledgment segment
1 1 0 0 CS Cancel segment from block sender
1 1 0 1 CAS Cancel-acknowledgment segment
to block sender
1 1 1 0 CR Cancel segment from block receiver
1 1 1 1 CAR Cancel-acknowledgment segment
to block receiver
1 1 - 0 Cx Cancel segment (generic)
1 1 - 1 CAx Cancel-acknowledgment segment
(generic)
3.1.4. Extensions Field
The Extensions field enables the inclusion of zero or more functional
extensions to the basic LTP segment, each in type-length-value (TLV)
representation as explained below.
Ramadas, et al. Experimental [Page 14]
^L
RFC 5326 LTP - Specification September 2008
The first octet of the Extensions field indicates the number of
extensions present in the segment: the high-order 4 bits indicate the
number of extension TLVs in the header (immediately following the
extensions count octet and preceding the segment's content), while
the low-order 4 bits indicate the number of extension TLVs in the
trailer (immediately following the segment's content). That is, each
segment may have from 0 to 15 extension TLVs in its header and from 0
to 15 extension TLVs in its trailer. In the absence of any extension
TLVs, all bits of this extensions count octet MUST be set to zero.
Note that it is valid for header extensions to be immediately
followed by trailer extensions; for example, since a CAx segment has
no contents, it may have header extensions immediately followed by
trailer extensions.
Each extension consists of a one-octet tag identifying the type of
the extension, followed by a length parameter in SDNV form, followed
by a value of the specified length.
The diagram below illustrates the extension TLVs as they may occur in
the header or trailer.
+--------+----///-----///--+
|ext-tag | length | value |
+--------+-------///-------+----------///-------+
|ext-tag | length | value |
+--------+-----///-----///-+---------////-------+
|ext-tag | length | value |
+--------+----------+----------+
The IANA maintains an LTP Extension Tag registry as shown below. See
the IANA considerations section below for details of code point
assignment in the Unassigned range.
Extension tag Meaning
------------- -------
0x00 LTP authentication extension [LTPEXT]
0x01 LTP cookie extension [LTPEXT]
0x02-0xAF Unassigned
0xB0-0xBF Reserved
0xC0-0xFF Private / Experimental Use
Note that since the last quarter of the extension-tag space is for
experimental use, implementations should be aware that collisions for
these tags are possible.
Ramadas, et al. Experimental [Page 15]
^L
RFC 5326 LTP - Specification September 2008
3.2. Segment Content
3.2.1. Data Segment (DS)
The content of a data segment includes client service data and the
metadata enabling the receiving client service instance to receive
and make use of that data.
Client service ID (SDNV)
The client service ID number identifies the upper-level service to
which the segment is to be delivered by the receiver. It is
functionally analogous to a TCP port number. If multiple
instances of the client service are present at the destination,
multiplexing must be done by the client service itself on the
basis of information encoded within the transmitted block.
Offset (SDNV)
Offset indicates the location of the segment's client service data
within the session's transmitted block. It is the number of bytes
in the block prior to the byte from which the first octet of the
segment's client service data was copied.
Length (SDNV)
The length of the ensuing client service data, in octets.
If the data segment is a checkpoint, the segment MUST additionally
include the following two serial numbers (checkpoint serial number
and report serial number) to support efficient retransmission. Data
segments that are not checkpoints MUST NOT have these two fields in
the header and MUST continue on directly with the client service
data.
Checkpoint serial number (SDNV)
The checkpoint serial number uniquely identifies the checkpoint
among all checkpoints issued by the block sender in a session.
The first checkpoint issued by the sender MUST have this serial
number chosen randomly for security reasons, and it is RECOMMENDED
that the sender use the guidelines in [ESC05] for this. Any
subsequent checkpoints issued by the sender MUST have the serial
number value found by incrementing the prior checkpoint serial
number by 1. When a checkpoint segment is retransmitted, however,
its serial number MUST be the same as when it was originally
transmitted. The checkpoint serial number MUST NOT be zero.
Ramadas, et al. Experimental [Page 16]
^L
RFC 5326 LTP - Specification September 2008
Report serial number (SDNV)
If the checkpoint was queued for transmission in response to the
reception of an RS (Section 6.13), then its value MUST be the
report serial number value of the RS that caused the data segment
to be queued for transmission.
Otherwise, the value of report serial number MUST be zero.
Client service data (array of octets)
The client service data carried in the segment is a copy of a
subset of the bytes in the original client service data block,
starting at the indicated offset.
3.2.2. Report Segment (RS)
The content of an RS comprises one or more data reception claims,
together with the upper and lower bounds of the scope within the data
block to which the claims pertain. It also includes two serial
numbers to support efficient retransmission.
Report serial number (SDNV)
The report serial number uniquely identifies the report among all
reports issued by the receiver in a session. The first report
issued by the receiver MUST have this serial number chosen
randomly for security reasons, and it is RECOMMENDED that the
receiver use the guidelines in [ESC05] for this. Any subsequent
RS issued by the receiver MUST have the serial number value found
by incrementing the last report serial number by 1. When an RS is
retransmitted however, its serial number MUST be the same as when
it was originally transmitted. The report serial number MUST NOT
be zero.
Checkpoint serial number (SDNV)
The value of the checkpoint serial number MUST be zero if the
report segment is NOT a response to reception of a checkpoint,
i.e., the reception report is asynchronous; otherwise, it MUST be
the checkpoint serial number of the checkpoint that caused the RS
to be issued.
Upper bound (SDNV)
The upper bound of a report segment is the size of the block
prefix to which the segment's reception claims pertain.
Ramadas, et al. Experimental [Page 17]
^L
RFC 5326 LTP - Specification September 2008
Lower bound (SDNV)
The lower bound of a report segment is the size of the (interior)
block prefix to which the segment's reception claims do NOT
pertain.
Reception claim count (SDNV)
The number of data reception claims in this report segment.
Reception claims
Each reception claim comprises two elements: offset and length.
Offset (SDNV)
The offset indicates the successful reception of data beginning
at the indicated offset from the lower bound of the RS. The
offset within the entire block can be calculated by summing
this offset with the lower bound of the RS.
Length (SDNV)
The length of a reception claim indicates the number of
contiguous octets of block data starting at the indicated
offset that have been successfully received.
Reception claims MUST conform to the following rules:
A reception claim's length shall never be less than 1 and shall
never exceed the difference between the upper and lower bounds
of the report segment.
The offset of a reception claim shall always be greater than
the sum of the offset and length of the prior claim, if any.
The sum of a reception claim's offset and length and the lower
bound of the report segment shall never exceed the upper bound
of the report segment.
Implied requests for retransmission of client service data can be
inferred from an RS's data reception claims. However, *nothing* can
be inferred regarding reception of block data at any offset equal to
or greater than the segment's upper bound or at any offset less than
the segment's lower bound.
Ramadas, et al. Experimental [Page 18]
^L
RFC 5326 LTP - Specification September 2008
For example, if the scope of a report segment has lower bound 0 and
upper bound 6000, and the report contains a single data reception
claim with offset 0 and length 6000, then the report signifies
successful reception of the first 6000 bytes of the block. If the
total length of the block is 6000, then the report additionally
signifies successful reception of the entire block.
If on the other hand, the scope of a report segment has lower bound
1000 and upper bound 6000, and the report contains two data reception
claims, one with offset 0 and length 2000 and the other with offset
3000 and length 500, then the report signifies successful reception
only of bytes 1000-2999 and 4000-4499 of the block. From this we can
infer that bytes 3000-3999 and 4500-5999 of the block need to be
retransmitted, but we cannot infer anything about reception of the
first 1000 bytes or of any subsequent data beginning at block offset
6000.
3.2.3. Report Acknowledgment Segment
The content of an RA is simply the report serial number of the RS in
response to which the segment was generated.
Report serial number (SDNV)
This field returns the report serial number of the RS being
acknowledged.
Ramadas, et al. Experimental [Page 19]
^L
RFC 5326 LTP - Specification September 2008
3.2.4. Session Management Segments
Cancel segments (Cx) carry a single byte reason-code with the
following semantics:
Reason-Code Mnemonic Semantics
----------- -------- ---------------------------------------
00 USR_CNCLD Client service canceled session.
01 UNREACH Unreachable client service.
02 RLEXC Retransmission limit exceeded.
03 MISCOLORED Received either a red-part data segment
at block offset above any green-part
data segment offset or a green-part
data segment at block offset below any
red-part data segment offset.
04 SYS_CNCLD A system error condition caused
unexpected session termination.
05 RXMTCYCEXC Exceeded the Retransmission-Cycles limit.
06-FF Reserved
The Cancel-acknowledgments (CAx) have no content.
Note: The reason we use different cancel segment types for the
originator and recipient is to allow a loopback mode to work without
disturbing any replay protection mechanism in use.
3.3. Segment Trailer
The segment trailer consists of a sequence of zero to 15 extension
TLVs as described in Section 3.1.4 above.
4. Requests from Client Service
In all cases, the representation of request parameters is a local
implementation matter, as are validation of parameter values and
notification of the client service in the event that a request is
found to be invalid.
Ramadas, et al. Experimental [Page 20]
^L
RFC 5326 LTP - Specification September 2008
4.1. Transmission Request
In order to request transmission of a block of client service data,
the client service MUST provide the following parameters to LTP:
Destination client service ID.
Destination LTP engine ID.
Client service data to send, as an array of bytes.
Length of the data to be sent.
Length of the red-part of the data. This value MUST be in the
range from zero to the total length of data to be sent.
On reception of a valid transmission request from a client service,
LTP proceeds as follows.
First, the array of data to be sent is subdivided as necessary, with
each subdivision serving as the client service data of a single new
LTP data segment. The algorithm used for subdividing the data is a
local implementation matter; it is expected that data size
constraints imposed by the underlying communication service, if any,
will be accommodated in this algorithm.
The last (and only the last) of the resulting data segments must be
marked as the EOB (end of block).
Note that segment type indicates that the client service data in a
given LTP segment either is or is not in the red-part of the block.
To prevent segment type ambiguity, each data segment MUST contain
either only red-part data or only green-part data. Therefore, when
the length of the block's red-part is N, the total length of the
block is M, and N is not equal to M, the (N+1)th byte of the block
SHOULD be the first byte of client service data in a green-part data
segment. Note that this means that at the red-part boundary, LTP may
send a segment of size lesser than the link MTU size. For bandwidth
efficiency reasons, implementations MAY choose to instead mark the
entire segment (within which the red-part boundary falls) as red-
part, causing green-part data falling within the segment to also be
treated as red-part.
If the length of the block's red-part is greater than zero, then the
last data segment containing red-part data must be marked as the EORP
(end of red-part) segment by setting the appropriate segment type
flag bits (Section 3.1.2). Zero or more preceding data segments
containing red-part data (selected according to an algorithm that is
Ramadas, et al. Experimental [Page 21]
^L
RFC 5326 LTP - Specification September 2008
a local implementation matter) MAY additionally be marked as a CP
(Checkpoint), and serve as additional discretionary checkpoints
(Section 3.1.2).
All data segments are appended to the (conceptual) application data
queue bound for the destination engine, for subsequent transmission.
Finally, a session start notice (Section 7.1) is sent back to the
client service that requested the transmission.
4.2. Cancellation Request
In order to request cancellation of a session, either as the sender
or as the receiver of the associated data block, the client service
must provide the session ID identifying the session to be canceled.
On reception of a valid cancellation request from a client service,
LTP proceeds as follows.
First, the internal "Cancel Session" procedure (Section 6.19) is
invoked.
Next, if the session is being canceled by the sender (i.e., the
session originator part of the session ID supplied in the
cancellation request is the local LTP engine ID):
- If none of the data segments previously queued for transmission
as part of this session have yet been de-queued and transmitted
-- i.e., if the destination engine cannot possibly be aware of
this session -- then the session is simply closed; the "Close
Session" procedure (Section 6.20) is invoked.
- Otherwise, a CS (cancel by block sender) segment with the
reason-code USR_CNCLD MUST be queued for transmission to the
destination LTP engine specified in the transmission request
that started this session.
Otherwise (i.e., the session is being canceled by the receiver):
- If there is no transmission queue-set bound for the sender
(possibly because the local LTP engine is running on a receive-
only device), then the session is simply closed; the "Close
Session" procedure (Section 6.20) is invoked.
- Otherwise, a CR (cancel by block receiver) segment with reason-
code USR_CNCLD MUST be queued for transmission to the block
sender.
Ramadas, et al. Experimental [Page 22]
^L
RFC 5326 LTP - Specification September 2008
5. Requirements from the Operating Environment
LTP is designed to run directly over a data-link layer protocol.
LTP MUST only be deployed directly over UDP, for software development
purposes or for use in private local area networks, for example, in a
sparse sensor network where the link, when available, is only used
for LTP traffic.
In either case, the protocol layer immediately underlying LTP is
referred to as the "local data-link layer" for the purposes of this
specification.
When the local data-link layer protocol is UDP, (a) the content of
each UDP datagram MUST be an integral number of LTP segments and (b)
the LTP authentication [LTPEXT] extension SHOULD be used unless the
end-to-end path is one in which either the likelihood of datagram
content corruption is negligible or the consequences of receiving and
processing corrupt LTP segments are insignificant (as during software
development). In addition, the LTP authentication [LTPEXT] extension
SHOULD be used to ensure data integrity unless the end-to-end path is
one in which either the likelihood of datagram content corruption is
negligible (as in some private local area networks) or the
consequences of receiving and processing corrupt LTP segments are
insignificant (as perhaps during software development).
When the local data-link layer protocol is not UDP, the content of
each local data-link layer protocol frame MUST be an integral number
of LTP segments.
The local data-link layer protocol MUST be a protocol that, together
with the operating environment in which that protocol is implemented,
satisfies the following requirements:
- It is required to inform LTP whenever the link to a specific LTP
destination is brought up or torn down. Similarly, it is
required to inform the local LTP engine whenever it is known
that a remote LTP engine is set to begin or stop communication
with the local engine based on the engines' operating schedules.
- It is required to provide link state cues to LTP upon
transmission of the CP, RS (report), EORP, EOB, and Cx (cancel)
segments so that timers can be started.
- It is required to provide, upon request, the current distance
(in light seconds) to any peer engine in order to calculate
timeout intervals.
Ramadas, et al. Experimental [Page 23]
^L
RFC 5326 LTP - Specification September 2008
A MIB (Management Information Base) with the above parameters,
updated periodically by the local data-link layer and the operating
environment, should be made available to the LTP engine for its
operations. The details of the MIB are, however, beyond the scope of
this document.
The underlying data-link layer is required to never deliver
incompletely received LTP segments to LTP. In the absence of the use
of LTP authentication [LTPEXT], LTP also requires the underlying
local data-link layer protocol to perform data integrity checking of
the segments received. Specifically, the local data-link layer
protocol is required to detect any corrupted segments received and to
silently discard them.
6. Internal Procedures
This section describes the internal procedures that are triggered by
the occurrence of various events during the lifetime of an LTP
session.
Whenever the content of any of the fields of the header of any
received LTP segment does not conform to this specification document,
the segment is assumed to be corrupt and MUST be discarded
immediately and processed no further. This procedure supersedes all
other procedures described below.
All internal procedures described below that are triggered by the
arrival of a data segment are superseded by the following procedure
in the event that the client service identified by the data segment
does not exist at the local LTP engine:
- If there is no transmission queue-set bound for the block sender
(possibly because the local LTP engine is running on a receive-
only device), then the received data segment is simply
discarded.
- Otherwise, if the data segment contains data from the red-part
of the block, a CR with reason-code UNREACH MUST be enqueued for
transmission to the block sender. A CR with reason-code UNREACH
SHOULD be similarly enqueued for transmission to the data sender
even if the data segment contained data from the green-part of
the block; note however that (for example) in the case where the
block receiver knows that the sender of this green-part data is
functioning in a "beacon" (transmit-only) fashion, a CR need not
be sent. In either case, the received data segment is
discarded.
Ramadas, et al. Experimental [Page 24]
^L
RFC 5326 LTP - Specification September 2008
6.1. Start Transmission
This procedure is triggered by the arrival of a link state cue
indicating the start of transmission to a specified remote LTP
engine.
Response: the de-queuing and delivery of segments to the LTP engine
specified in the link state cue begins.
6.2. Start Checkpoint Timer
This procedure is triggered by the arrival of a link state cue
indicating the de-queuing (for transmission) of a CP segment.
Response: the expected arrival time of the RS segment that will be
produced on reception of this CP segment is computed, and a countdown
timer is started for this arrival time. However, if it is known that
the remote LTP engine has ceased transmission (Section 6.5), then
this timer is immediately suspended, because the computed expected
arrival time may require an adjustment that cannot yet be computed.
6.3. Start RS Timer
This procedure is triggered by the arrival of a link state cue
indicating the de-queuing (for transmission) of an RS segment.
Response: the expected arrival time of the RA (report acknowledgment)
segment in response to the reception of this RS segment is computed,
and a countdown timer is started for this arrival time. However, as
in Section 6.2, if it is known that the remote LTP engine has ceased
transmission (Section 6.5), then this timer is immediately suspended,
because the computed expected arrival time may require an adjustment
that cannot yet be computed.
6.4. Stop Transmission
This procedure is triggered by the arrival of a link state cue
indicating the cessation of transmission to a specified remote LTP
engine.
Response: the de-queuing and delivery to the underlying communication
system of segments from traffic queues bound for the LTP engine
specified in the link state cue ceases.
Ramadas, et al. Experimental [Page 25]
^L
RFC 5326 LTP - Specification September 2008
6.5. Suspend Timers
This procedure is triggered by the arrival of a link state cue
indicating the cessation of transmission from a specified remote LTP
engine to the local LTP engine. Normally, this event is inferred
from advance knowledge of the remote engine's planned transmission
schedule.
Response: countdown timers for the acknowledging segments that the
remote engine is expected to return are suspended as necessary based
on the following procedure.
The nominal remote engine acknowledge transmission time is computed
as the sum of the transmission time of the original segment (to which
the acknowledging segment will respond) and the one-way light time to
the remote engine, plus N seconds of "additional anticipated latency"
(AAL) encompassing anticipated transmission delays other than signal
propagation time. N is determined in an implementation-specific
manner. For example, when LTP is deployed in deep-space vehicles,
the one-way light time to the remote engine may be very large while N
may be relatively small, covering processing and queuing delays. N
may be a network management parameter, for which 2 seconds seems like
a reasonable default value. As another example, when LTP is deployed
in a terrestrial "data mule" environment, one-way light time latency
is effectively zero while N may need to be some dynamically computed
function of the data mule circulation schedule.
If the nominal remote engine acknowledge transmission time is greater
than or equal to the current time (i.e., the acknowledging segment
may be presented for transmission during the time that transmission
at the remote engine is suspended), then the countdown timer for this
acknowledging segment is suspended.
6.6. Resume Timers
This procedure is triggered by the arrival of a link state cue
indicating the start of transmission from a specified remote LTP
engine to the local LTP engine. Normally, this event is inferred
from advance knowledge of the remote engine's planned transmission
schedule.
Response: expected arrival time is adjusted for every acknowledging
segment that the remote engine is expected to return, for which the
countdown timer has been suspended. First, the transmission delay
interval is calculated as follows:
Ramadas, et al. Experimental [Page 26]
^L
RFC 5326 LTP - Specification September 2008
- The nominal remote engine acknowledge transmission time is
computed as the sum of the transmission time of the original
segment (to which the acknowledging segment will respond) and
the one-way light time to the remote engine, plus N seconds of
AAL Section 6.5.
- If the nominal remote engine acknowledge transmission time is
greater than the current time, i.e., the remote engine resumed
transmission prior to presentation of the acknowledging segment
for transmission, then the transmission delay interval is zero.
- Otherwise, the transmission delay interval is computed as the
current time less the nominal remote engine acknowledge
transmission time.
The expected arrival time is increased by the computed transmission
delay interval for each of the suspended countdown timers, and the
timers are resumed.
6.7. Retransmit Checkpoint
This procedure is triggered by the expiration of a countdown timer
associated with a CP segment.
Response: if the number of times this CP segment has been queued for
transmission exceeds the checkpoint retransmission limit established
for the local LTP engine by network management, then the session of
which the segment is one token is canceled: the "Cancel Session"
procedure (Section 6.19) is invoked, a CS with reason-code RLEXC is
appended to the (conceptual) application data queue, and a
transmission-session cancellation notice (Section 7.5) is sent back
to the client service that requested the transmission.
Otherwise, a new copy of the CP segment is appended to the
(conceptual) application data queue for the destination LTP engine.
6.8. Retransmit RS
This procedure is triggered by either (a) the expiration of a
countdown timer associated with an RS segment or (b) the reception of
a CP segment for which one or more RS segments were previously issued
-- a redundantly retransmitted checkpoint.
Response: if the number of times any affected RS segment has been
queued for transmission exceeds the report retransmission limit
established for the local LTP engine by network management, then the
session of which the segment is one token is canceled: the "Cancel
Session" procedure (Section 6.19) is invoked, a CR segment with
Ramadas, et al. Experimental [Page 27]
^L
RFC 5326 LTP - Specification September 2008
reason-code RLEXC is queued for transmission to the LTP engine that
originated the session, and a reception-session cancellation notice
(Section 7.6) is sent to the client service identified in each of the
data segments received in this session.
Otherwise, a new copy of each affected RS segment is queued for
transmission to the LTP engine that originated the session.
6.9. Signify Red-Part Reception
This procedure is triggered by the arrival of a CP segment when the
EORP for this session has been received (ensuring that the size of
the data block's red-part is known; this includes the case where the
CP segment itself is the EORP segment) and all data in the red-part
of the block being transmitted in this session have been received.
Response: a red-part reception notice (Section 7.3) is sent to the
specified client service.
6.10. Signify Green-Part Segment Arrival
This procedure is triggered by the arrival of a data segment whose
content is a portion of the green-part of a block.
Response: a green-part segment arrival notice (Section 7.2) is sent
to the specified client service.
6.11. Send Reception Report
This procedure is triggered by either (a) the original reception of a
CP segment (the checkpoint serial number identifying this CP is new)
(b) an implementation-specific circumstance pertaining to a
particular block reception session for which no EORP has yet been
received ("asynchronous" reception reporting).
Response: if the number of reception problems detected for this
session exceeds a limit established for the local LTP engine by
network management, then the affected session is canceled: the
"Cancel Session" procedure (Section 6.19) is invoked, a CR segment
with reason-code RLEXC is issued and is, in concept, appended to the
queue of internal operations traffic bound for the LTP engine that
originated the session, and a reception-session cancellation notice
(Section 7.6) is sent to the client service identified in each of the
data segments received in this session. One possible limit on
reception problems would be the maximum number of reception reports
that can be issued for any single session.
Ramadas, et al. Experimental [Page 28]
^L
RFC 5326 LTP - Specification September 2008
If such a limit is not reached, a reception report is issued as
follows.
If production of the reception report was triggered by reception of a
checkpoint:
- The upper bound of the report SHOULD be the upper bound (the sum
of the offset and length) of the checkpoint data segment, to
minimize unnecessary retransmission. Note: If a discretionary
checkpoint is lost but subsequent segments are received, then by
the time the retransmission of the lost checkpoint is received
the receiver would have segments at block offsets beyond the
upper bound of the checkpoint. For deployments where bandwidth
economy is not critical, the upper bound of a synchronous
reception report MAY be the maximum upper bound value among all
red-part data segments received so far in the affected session.
- If the checkpoint was itself issued in response to a report
segment, then this report is a "secondary" reception report. In
that case, the lower bound of the report SHOULD be the lower
bound of the report segment to which the triggering checkpoint
was itself a response, to minimize unnecessary retransmission.
Note: For deployments where bandwidth economy is not critical,
the lower bound of the report MAY instead be zero.
- If the checkpoint was not issued in response to a report
segment, this report is a "primary" reception report. The lower
bound of the first primary reception report issued for any
session MUST be zero. The lower bound of each subsequent
primary reception report issued for the same session SHOULD be
the upper bound of the prior primary reception report issued for
the session, to minimize unnecessary retransmission. Note: For
deployments where bandwidth economy is not critical, the lower
bound of every primary reception report MAY be zero.
If production of the reception report is "asynchronous" as noted
above:
- The upper bound of the report MUST be the maximum upper bound
among all red-part data segments received so far for this
session.
- The lower bound of the first asynchronous reception report
issued for any session for which no other primary reception
reports have yet been issued MUST be zero. The lower bound of
each subsequent asynchronous reception report SHOULD be the
upper bound of the prior primary reception report issued for the
Ramadas, et al. Experimental [Page 29]
^L
RFC 5326 LTP - Specification September 2008
session, to minimize unnecessary retransmission. Note: For
deployments where bandwidth economy is not critical, the lower
bound of every asynchronous reception report MAY be zero.
In all cases, if the applicable lower bound of the scope of a report
is determined to be greater than or equal to the applicable upper
bound (for example, due to out-of-order arrival of discretionary
checkpoints) then the reception report MUST NOT be issued.
Otherwise:
As many RS segments must be produced as are needed in order to report
on all data reception within the scope of the report, given whatever
data size constraints are imposed by the underlying communication
service. The RS segments are, in concept, appended to the queue of
internal operations traffic bound for the LTP engine that originated
the indicated session. The lower bound of the first RS segment of
the report MUST be the reception report's lower bound. The upper
bound of the last RS segment of the report MUST be the reception
report's upper bound.
6.12. Signify Transmission Completion
This procedure is triggered at the earliest time at which (a) all
data in the block are known to have been transmitted *and* (b) the
entire red-part of the block -- if of non-zero length -- is known to
have been successfully received. Condition (a) is signaled by
arrival of a link state cue indicating the de-queuing (for
transmission) of the EOB segment for the block. Condition (b) is
signaled by reception of an RS segment whose reception claims, taken
together with the reception claims of all other RS segments
previously received in the course of this session, indicate complete
reception of the red-part of the block.
Response: a transmission-session completion notice (Section 7.4) is
sent to the local client service associated with the session, and the
session is closed: the "Close Session" procedure (Section 6.20) is
invoked.
6.13. Retransmit Data
This procedure is triggered by the reception of an RS segment.
Response: first, an RA segment with the same report serial number as
the RS segment is issued and is, in concept, appended to the queue of
internal operations traffic bound for the receiver. If the RS
segment is redundant -- i.e., either the indicated session is unknown
(for example, the RS segment is received after the session has been
completed or canceled) or the RS segment's report serial number
Ramadas, et al. Experimental [Page 30]
^L
RFC 5326 LTP - Specification September 2008
matches that of an RS segment that has already been received and
processed -- then no further action is taken. Otherwise, the
procedure below is followed.
If the report's checkpoint serial number is not zero, then the
countdown timer associated with the indicated checkpoint segment is
deleted.
Note: All retransmission buffer space occupied by data whose
reception is claimed in the report segment can (in concept) be
released.
If the segment's reception claims indicate incomplete data reception
within the scope of the report segment:
- If the number of transmission problems for this session exceeds
a limit established for the local LTP engine by network
management, then the session of which the segment is one token
is canceled: the "Cancel Session" procedure (Section 6.19) is
invoked, a CS with reason-code RLEXC is appended to the
transmission queue specified in the transmission request that
started this session, and a transmission-session cancellation
notice (Section 7.5) is sent back to the client service that
requested the transmission. One possible limit on transmission
problems would be the maximum number of retransmission CP
segments that may be issued for any single session.
- If the number of transmission problems for this session has not
exceeded any limit, new data segments encapsulating all block
data whose non-reception is implied by the reception claims are
appended to the transmission queue bound for the receiver. The
last -- and only the last -- data segment must be marked as a CP
segment carrying a new CP serial number (obtained by
incrementing the last CP serial number used) and the report
serial number of the received RS segment.
6.14. Stop RS Timer
This procedure is triggered by the reception of an RA.
Response: the countdown timer associated with the original RS segment
(identified by the report serial number of the RA segment) is
deleted. If no other countdown timers associated with RS segments
exist for this session, then the session is closed: the "Close
Session" procedure (Section 6.20) is invoked.
Ramadas, et al. Experimental [Page 31]
^L
RFC 5326 LTP - Specification September 2008
6.15. Start Cancel Timer
This procedure is triggered by arrival of a link state cue indicating
the de-queuing (for transmission) of a Cx segment.
Response: the expected arrival time of the CAx segment that will be
produced on reception of this Cx segment is computed and a countdown
timer for this arrival time is started. However, if it is known that
the remote LTP engine has ceased transmission (Section 6.5), then
this timer is immediately suspended, because the computed expected
arrival time may require an adjustment that cannot yet be computed.
6.16. Retransmit Cancellation Segment
This procedure is triggered by the expiration of a countdown timer
associated with a Cx segment.
Response: if the number of times this Cx segment has been queued for
transmission exceeds the cancellation retransmission limit
established for the local LTP engine by network management, then the
session of which the segment is one token is simply closed: the
"Close Session" procedure (Section 6.20) is invoked.
Otherwise, a copy of the cancellation segment (retaining the same
reason-code) is queued for transmission to the appropriate LTP
engine.
6.17. Acknowledge Cancellation
This procedure is triggered by the reception of a Cx segment.
Response: in the case of a CS segment where there is no transmission
queue-set bound for the sender (possibly because the receiver is a
receive-only device), then no action is taken. Otherwise:
- If the received segment is a CS segment, a CAS (cancel
acknowledgment to block sender) segment is issued and is, in
concept, appended to the queue of internal operations traffic
bound for the sender.
- If the received segment is a CR segment, a CAR (cancel
acknowledgment to block receiver) segment is issued and is, in
concept, appended to the queue of internal operations traffic
bound for the receiver.
Ramadas, et al. Experimental [Page 32]
^L
RFC 5326 LTP - Specification September 2008
It is possible that the Cx segment has been retransmitted because a
previous responding acknowledgment CAx (cancel acknowledgment)
segment was lost, in which case there will no longer be any record of
the session of which the segment is one token. If so, no further
action is taken.
Otherwise: the "Cancel Session" procedure (Section 6.19) is invoked
and a reception-session cancellation notice (Section 7.6) is sent to
the client service identified in each of the data segments received
in this session. Finally, the session is closed: the "Close Session"
procedure (Section 6.20) is invoked.
6.18. Stop Cancel Timer
This procedure is triggered by the reception of a CAx segment.
Response: the timer associated with the Cx segment is deleted, and
the session of which the segment is one token is closed, i.e., the
"Close Session" procedure (Section 6.20) is invoked.
6.19. Cancel Session
This procedure is triggered internally by one of the other procedures
described above.
Response: all segments of the affected session that are currently
queued for transmission can be deleted from the outbound traffic
queues. All countdown timers currently associated with the session
are deleted. Note: If the local LTP engine is the sender, then all
remaining data retransmission buffer space allocated to the session
can be released.
6.20. Close Session
This procedure is triggered internally by one of the other procedures
described above.
Response: any remaining countdown timers associated with the session
are deleted. The session state record (SSR|RSR) for the session is
deleted; existence of the session is no longer recognized.
6.21. Handle Miscolored Segment
This procedure is triggered by the arrival of either (a) a red-part
data segment whose block offset begins at an offset higher than the
block offset of any green-part data segment previously received for
the same session or (b) a green-part data segment whose block offset
is lower than the block offset of any red-part data segment
Ramadas, et al. Experimental [Page 33]
^L
RFC 5326 LTP - Specification September 2008
previously received for the same session. The arrival of a segment
matching either of the above checks is a violation of the protocol
requirement of having all red-part data as the block prefix and all
green-part data as the block suffix.
Response: the received data segment is simply discarded.
The Cancel Session procedure (Section 6.19) is invoked and a CR
segment with reason-code MISCOLORED SHOULD be enqueued for
transmission to the data sender.
Note: If there is no transmission queue-set bound for the sender
(possibly because the local LTP engine is running on a receive-only
device), or if the receiver knows that the sender is functioning in a
"beacon" (transmit-only) fashion, a CR segment need not be sent.
A reception-session cancellation notice (Section 7.6) is sent to the
client service.
6.22. Handling System Error Conditions
It is possible (especially for long-lived LTP sessions) that an
unexpected operating system error condition may occur during the
lifetime of an LTP session. An example is the case where the system
faces severe memory crunch forcing LTP sessions into a scenario
similar to that of TCP SACK [SACK] reneging. But unlike TCP SACK
reception reports, which are advisory, LTP reception reports are
binding, and reneging is NOT permitted on previously made reception
claims.
Under any such irrecoverable system error condition, the following
response is to be initiated: the Cancel Session procedure (Section
6.19) is invoked. If the error condition is observed on the sender,
a CS segment with reason-code SYS_CNCLD SHOULD be enqueued for
transmission to the receiver, and a transmission-session cancellation
notice (Section 7.5) is sent to the client service; on the other
hand, if it is observed on the receiver, a CR segment with the same
reason-code SYS_CNCLD SHOULD be enqueued for transmission to the
sender, and a reception-session cancellation notice (Section 7.6) is
sent to the client service.
Note that as in (Section 6.21), if there is no transmission queue-set
bound for the sender (possibly because the local LTP engine is
running on a receive-only device), or if the receiver knows that the
sender of this green-part data is functioning in a "beacon"
(transmit-only) fashion, a CR segment need not be sent.
Ramadas, et al. Experimental [Page 34]
^L
RFC 5326 LTP - Specification September 2008
There may be other implementation-specific limits that may cause an
LTP implementation to initiate session-cancellation procedures. One
such limit is the maximum number of retransmission-cycles seen. A
retransmission cycle at the LTP Sender comprises the two related
events: the transmission of all outstanding CP segments from the
sender, and the reception of all RS segments issued from the receiver
in response to those CP segments. A similar definition would apply
at the LTP Receiver but relate to the reception of the CP segments
and transmission of all RS segments in response. Note that the
retransmitted CP and RS segments remain part of their original
retransmission-cycle. Also, a single CP segment may cause multiple
RS segments to be generated if a reception report would not fit in a
single data link-MTU-sized RS segment; all RS segments that are part
of a reception report belong to the same retransmission cycle to
which the CP segment belongs. In the presence of severe channel
error conditions, many retransmission cycles may elapse before red-
part transmission is deemed successful; an implementation may
therefore impose a retransmission-cycle limit to shield itself from a
resource-crunch situation. If an LTP sender notices the
retransmission-cycle limit being exceeded, it SHOULD initiate the
Cancel Session procedure (Section 6.19), queuing a CS segment with
reason-code RXMTCYCEXC and sending a transmission-session
cancellation notice (Section 7.5) to the client service.
7. Notices to Client Service
In all cases, the representation of notice parameters is a local
implementation matter.
7.1. Session Start
The Session Start notice returns the session ID identifying a newly
created session.
At the sender, the session start notice informs the client service of
the initiation of the transmission session. On receiving this notice
the client service may, for example, release resources of its own
that are allocated to the block being transmitted, or remember the
session ID so that the session can be canceled in the future if
necessary. At the receiver, this notice indicates the beginning of a
new reception session, and is delivered upon arrival of the first
data segment carrying a new session ID.
Ramadas, et al. Experimental [Page 35]
^L
RFC 5326 LTP - Specification September 2008
7.2. Green-Part Segment Arrival
The following parameters are provided by the LTP engine when a green-
part segment arrival notice is delivered:
Session ID of the transmission session.
Array of client service data bytes contained in the data segment.
Offset of the data segment's content from the start of the block.
Length of the data segment's content.
Indication as to whether or not the last byte of this data
segment's content is also the end of the block.
Source LTP engine ID.
7.3. Red-Part Reception
The following parameters are provided by the LTP engine when a red-
part reception notice is delivered:
Session ID of the transmission session.
Array of client service data bytes that constitute the red-part of
the block.
Length of the red-part of the block.
Indication as to whether or not the last byte of the red-part is
also the end of the block.
Source LTP engine ID.
7.4. Transmission-Session Completion
The sole parameter provided by the LTP engine when a transmission-
session completion notice is delivered is the session ID of the
transmission session.
A transmission-session completion notice informs the client service
that all bytes of the indicated data block have been transmitted and
that the receiver has received the red-part of the block.
Ramadas, et al. Experimental [Page 36]
^L
RFC 5326 LTP - Specification September 2008
7.5. Transmission-Session Cancellation
The parameters provided by the LTP engine when a transmission-session
cancellation notice is delivered are:
Session ID of the transmission session.
The reason-code sent or received in the Cx segment that initiated
the cancellation sequence.
A transmission-session cancellation notice informs the client service
that the indicated session was terminated, either by the receiver or
else due to an error or a resource quench condition in the local LTP
engine. There is no assurance that the destination client service
instance received any portion of the data block.
7.6. Reception-Session Cancellation
The parameters provided by the LTP engine when a reception
cancellation notice is delivered are:
Session ID of the transmission session.
The reason-code explaining the cancellation.
A reception-session cancellation notice informs the client service
that the indicated session was terminated, either by the sender or
else due to an error or a resource quench condition in the local LTP
engine. No subsequent delivery notices will be issued for this
session.
7.7. Initial-Transmission Completion
The session ID of the transmission session is included with the
initial-transmission completion notice.
This notice informs the client service that all segments of a block
(both red-part and green-part) have been transmitted. This notice
only indicates that original transmission is complete; retransmission
of any lost red-part data segments may still be necessary.
Ramadas, et al. Experimental [Page 37]
^L
RFC 5326 LTP - Specification September 2008
8. State Transition Diagrams
The following mnemonics have been used in the sender and LTP receiver
state transition diagrams that follow:
TE Timer Expiry
RDS Regular Red Data Segment (NOT {CP|EORP|EOB})
GDS Regular Green Data Segment (NOT EOB)
RL EXC Retransmission Limit Exceeded
RP Red-Part
GP Green-Part
FG Fully-Green
Note that blocks represented in rectangles, as in
+---------+
| FG_XMIT |
+---------+
specify actual states in the state-transition diagrams, while blocks
represented with jagged edges, as in
/\/\/\/\
| Cncld |
\/\/\/\/
are either pointers to a state or place-holders for sequences of
state transitions.
Ramadas, et al. Experimental [Page 38]
^L
RFC 5326 LTP - Specification September 2008
8.1. Sender
LTP Sender State Transition Diagram
/\/\/\/\
| Cncld |
\/\/\/\/
+--------+ | +------+
Rcv CR; | V V V | Rcv RS;
Snd CAR | +-------------+ | Snd RA
+-------+ CLOSED +----+
+---------------------------->+------+------+
| | Blk. Trans. Req
| Zero RP +
| Xmit ________________________/ \ Non-Zero RP
| GDS; / \
| +---+ | +------------------+ | +------+
| | V V | /\/\ Rcv RS V V V |
| | +---------+ +<-| RX |<---+ +---------+ |
| +<-+ FG_XMIT | | \/\/ +---+ +--->+ Xmit RDS;
| +----+----+ | | RP_XMIT | |
| | | /\/\ +---+ +--->+ Xmit {RDS, CP};
+<--------+ +<-| CP |<---+ +-----+---+ Start CP Tmr
| Xmit \/\/ CP TE | \
| {GDS, EOB}; | |
| Xmit {RDS, CP, EORP}; | +-------+
| Start CP Tmr | |
| | |
| +------------------+ | +---+ | Xmit {RDS,
| | /\/\ Rcv RS V V V | | CP, EORP,
| +<-| RX |<---+ +---------+ | | EOB};
| | \/\/ +---+ | | | Start
| | | GP_XMIT +->+ | CP Tmr
| | /\/\ +---+ | Xmit |
| +<-| CP |<---+ +-----+---+ GDS; |
| \/\/ CP TE | |
| | |
| Xmit {GDS, EOB}; | +---------+
| | |
| +------------------+ | |
| | /\/\ Rcv RS V V V
| +<-| RX |<---+ +-------------+
| | \/\/ +---+ |
| | | WAIT_RP_ACK |
| | /\/\ +---+ |
| +<-| CP |<---+ +-----+-------+
| \/\/ CP TE | RP acknowledged fully;
| V
+----------------------------------------+
Ramadas, et al. Experimental [Page 39]
^L
RFC 5326 LTP - Specification September 2008
LTP Sender State Transition Diagram (contd.)
/\/\ /\/\
|CP| |CX |
\/\/ \/\/
| | | Snd CS,
| | RL EXC; | Start CS Tmr;
| | |
| | /\/\ | +---+
| +------>| CX | V V |
| \/\/ +---------+ | CS TE,
| | CS_SENT | | RL NOT EXC;
V RL NOT EXC; +-+--+--+-+ | Rxmt CS,
Rxmt CP, | | | | Restart
Start CP Tmr; CS TE, | | +---+ CS Tmr
RL EXC; | |
| | Rcv CAS;
V V
/\/\/\/\
| Cncld |
\/\/\/\/
/\/\
| RX |
\/\/
| Cncl CP Tmr (if any)
V Snd RA
+---------+ +----+
| CHK_RPT | | |
+-+--+----+ RP in scope V |
| | \ NOT rcvd. fully +---------+ | Rxmt
Redundant | | RP +--------------------->| RP_RXMT | | missing
RS rcvd; | | in scope +----+--+-+ | RDS;
| | rcvd. fully | | |
V V Rxmt last | +----+
missing RDS |
(marked CP) |
Start CP Tmr; |
V
Asynchronous cancel request may be received from the local client
service while the LTP sender is in any of the states shown. If it
was not already in the sequence of state transitions beginning at the
CX marker, the internal procedure Cancel Session (Section 6.19) is
followed, and the LTP sender moves from its current state into the
sequence beginning at the CX marker initiating session cancellation
with reason-code USR_CNCLD. From the CX marker, the CS segment with
appropriate reason-code (USR_CNCLD or RLEXC depending on how the CX
Ramadas, et al. Experimental [Page 40]
^L
RFC 5326 LTP - Specification September 2008
sequence was entered) is queued for transmission to the LTP receiver
and the sender enters the Cancel-from-Sender Sent (CS_SENT) state.
The internal procedure Start Cancel Timer (Section 6.15) is started
upon receiving a link state cue indicating the beginning of
transmission of the CS segment. Upon receiving the acknowledging CAS
segment from the receiver, the LTP sender moves to the CLOSED state
(via the 'Cncld' pointer). If the CS timer expires, the internal
procedure Retransmit Cancellation Segment (Section 6.16) is followed:
- If the network management set retransmission limit is exceeded,
the session is simply closed and the LTP sender follows the
Cncld marker to the CLOSED state. If the retransmission limit
is not exceeded however, the CS segment is queued for a
retransmission and the LTP sender stays in the CS_SENT state.
The CS timer is started upon receiving a link state cue
indicating the beginning of actual transmission according to the
internal procedure Start Cancel Timer (Section 6.15).
Asynchronous cancel request may also be received from the receiver
LTP in the form of a CR segment when the LTP sender is in any of the
states. Upon receiving such a CR segment, the internal procedure
Acknowledge Cancellation (Section 6.17) is invoked: The LTP sender
sends a CAR segment in response and returns to the CLOSED state.
The LTP sender stays in the CLOSED state until receiving a Block
Transmission Request (Blk. Trans. Req) from the client service
instance. Upon receiving the request, it moves to either the Fully
Green Transmission State (FG_XMIT) if no portion of the block was
requested to be transmitted as red or to the Red-Part Transmission
State (RP_XMIT) state if a non-zero block-prefix was requested to be
transmitted red.
In the FG_XMIT state, the block is segmented as multiple green LTP
data segments respecting the link MTU size and the segments are
queued for transmission to the remote engine. The last such segment
is marked as EOB, and the LTP sender returns to the CLOSED state
after queuing it for transmission.
Similarly, from the RP_XMIT state, multiple red data segments are
queued for transmission, respecting the link MTU size. The sender
LTP may optionally mark some of the red data segments as asynchronous
checkpoints; the internal procedure Start Checkpoint Timer (Section
6.2) is followed upon receiving a link state cue indicating the
transmission of the asynchronous checkpoints. If the block
transmission request comprises a non-zero green part, the LTP sender
marks the last red data segment as CP and EORP, and after queuing it
for transmission, moves to the Green Part Transmission (GP_XMIT)
state. If the block transmission request was fully red however, the
Ramadas, et al. Experimental [Page 41]
^L
RFC 5326 LTP - Specification September 2008
last red data segment is marked as CP, EORP, and EOB and the sender
LTP moves directly to the Wait-for-Red-Part-Acknowledgment
(WAIT_RP_ACK) state. In both of the above state-transitions, the
internal procedure Start Checkpoint Timer (Section 6.2) is followed
upon receiving a link state cue indicating the beginning of
transmission of the queued CP segments. In the GP_XMIT state, the
green-part of the block is segmented as green data segments and
queued for transmission to the LTP receiver; the last green segment
of the block is additionally marked as EOB, and after queueing it for
transmission the LTP sender moves to the WAIT_RP_ACK state.
While the LTP sender is at any of the RP_XMIT, GP_XMIT, or
WAIT_RP_ACK states, it might be interrupted by the occurrence of the
following events:
1. An RS might be received from the LTP receiver (either in
response to a previously transmitted CP segment or sent
asynchronously for accelerated retransmission). The LTP sender
then moves to perform the sequence of state transitions
beginning at the RX marker (second part of the diagram), and
retransmits data if necessary, illustrating the internal
procedure Retransmit Data (Section 6.13):
First, if the RS segment had a non-zero CP serial number, the
corresponding CP timer is canceled. Then an RA segment
acknowledging the received RS segment is queued for
transmission to the LTP receiver and the LTP sender moves to
the Check Report state (CHK_RPT). If the RS segment was
redundantly transmitted by the LTP receiver (possibly because
either the last transmitted RA segment got lost or the RS
segment timer expired prematurely at the receiver), the LTP
sender does nothing more and returns back to the interrupted
state. Similarly, if all red data within the scope of the RS
segment is reported as received, there is no work to be done
and the LTP sender returns to the interrupted state. However,
if the RS segment indicated incomplete reception of data within
its scope, the LTP sender moves to the Red-Part Retransmit
state (RP_RXMT) where missing red data segments within scope
are queued for transmission. The last such segment is marked
as a CP, and the LTP sender returns to the interrupted state.
The internal procedure (Section 6.2) is followed upon receiving
a link state cue indicating the beginning of transmission of
the CP segment.
2. A previously set CP timer might expire. Now the LTP sender
follows the states beginning at the CP marker (second part of
the diagram), and follows the internal procedure Retransmit
Checkpoint (Section 6.7):
Ramadas, et al. Experimental [Page 42]
^L
RFC 5326 LTP - Specification September 2008
If the CP Retransmission Limit set by network management for
the session has been exceeded, the LTP sender proceeds towards
canceling the session (with reason-code RLEXC) as indicated by
the sequence of state transitions following the CX marker.
Otherwise (if the Retransmission Limit is not exceeded yet),
the CP segment is queued for retransmission and the LTP sender
returns to the interrupted state. The internal procedure Start
Checkpoint Timer (Section 6.2) is started again upon receiving
a link state cue indicating the beginning of transmission of
the segment.
The LTP sender stays at the WAIT_RP_ACK state after reaching it until
the red-part data is fully acknowledged as received by the receiver
LTP, and then returns to the CLOSED state following the internal
procedure Close Session (Section 6.20).
Note that while at the CLOSED state, the LTP sender might receive an
RS segment (if the last transmitted RA segment before session close
got lost or if the LTP receiver retransmitted the RS segment
prematurely), in which case it retransmits an acknowledging RA
segment and stays in the CLOSED state. If the session was canceled
by the receiver by issuing a CR segment, the receiver may retransmit
the CR segment (either prematurely or because the acknowledging CAR
segment got lost). In this case, the LTP sender retransmits the
acknowledging CAR segment and stays in the CLOSED state.
Ramadas, et al. Experimental [Page 43]
^L
RFC 5326 LTP - Specification September 2008
8.2. Receiver
LTP Receiver State Transition Diagram
/\/\/\/\
+----+ +----+ Cncld |
Rcv CS; | V V \/\/\/\/
Snd CAS | +-------------+
+--+ CLOSED +<--------------------------+
+------+------+ |
+----+ | Rcv first DS |
Rcv RA; | V V |
Cncl RS Tmr | +--------+ |
+---+ DS_REC | |
+----------------------------->+-+--+-+-+<----------------------+---+ |
| Svc. does not exist | | | RS TE | | |
| /\/\ or Rcv miscolored seg. | | | /\/\ | | |
| | CX |<-----------------------+ | +------------->| RX |---->+ | |
| \/\/ | \/\/ | |
| Rcv RDS; | Rcv GDS; | |
| +-----------+------------+ | |
| V V | |
| /\/\ RS TE +--------------+ +--------+ | |
+<-| RX |<------+ RCV_RP | | RCV_GP | | |
| \/\/ +-+----+--+--+-+ +--+-+-+-+ | |
| | | | | | | | | |
| Rcvd RDS; | | | | Rcvd {RDS, CP, | | | RS TE /\/\ | |
| | | | | EORP, EOB}; | | +------>| RX |->+ |
+<----------------+ | | | Snd RS, | | \/\/ | |
| | | | Start RS Tmr | | Rcvd GDS; | |
| Rcvd {RDS, CP}; | | | | +---------------->+ |
| Snd RS, Start RS Tmr | | +-------+ +-----+ |
+<---------------------+ | | | Rcvd {GDS, EOB}; |
| | | | |
| | +-----+ | | +------+ |
| Rcvd {RDS, CP, EORP}; | | V V V V | |
| Snd RS, Start RS Tmr | | +----------------+ | Rcv RDS; |
| | | | +-->+ |
| | | | WAIT_RP_REC | | Rcv {RDS, CP}; |
| | | | +-->+ Snd RS, Start |
+<------------------------+ | +---+--+-+-+-----+ | RS Tmr |
| RS TE | | | | Rcv RA; | |
| V | | | Cncl | |
| /\/\ | | | RS Tmr | |
+---| RX | | | +-------->+ |
\/\/ | | |
/\/\ | | |
| CX |<------------------------+ | RP rcvd. fully |
\/\/ Rcv miscolored seg. +--------------------------->+
Ramadas, et al. Experimental [Page 44]
^L
RFC 5326 LTP - Specification September 2008
Receiver State Transition Diagram (contd.)
/\/\
| RX |
\/\/
| |
| | RL EXC; /\/\
RL NOT EXC; | +---------->| CX |
Rxmt RS, | \/\/
Start RS Tmr |
V
/\/\
| CX |
\/\/
| Snd CR,
| Start CR Tmr;
|
| +----+
V V |
+---------+ | CR TE,
| CR_SENT | | RL NOT EXC;
+-+--+--+-+ | Rxmt CR,
| | | | Restart
CR TE, | | +---+ CR Tmr
RL EXC; | |
| | Rcv CAR;
V V
/\/\/\/\
| Cncld |
\/\/\/\/
Asynchronous cancel requests are handled in a manner similar to the
way they are handled in the LTP sender. If the cancel request was
made from the local client service instance and the LTP receiver was
not already in the CR_SENT state, a CR segment with reason-code
USR_CNCLD SHOULD be sent to the LTP sender following the sequence of
state transitions beginning at the CX marker as described above. If
the asynchronous cancel request is received from the LTP sender, a
CAS segment is sent and the LTP receiver moves to the CLOSED state
(independent of the state the LTP receiver may be in).
The LTP receiver begins at the CLOSED state and enters the Data
Segment Reception (DS_REC) state upon receiving the first data
segment. If the client service ID referenced in the data segment was
non-existent, a Cx segment with reason-code UNREACH SHOULD be sent to
the LTP sender via the Cancellation sequence beginning with the CX
marker (second part of the diagram). If the received segment was
Ramadas, et al. Experimental [Page 45]
^L
RFC 5326 LTP - Specification September 2008
found to be miscolored, the internal procedure Handle Miscolored
Segment (Section 6.21) is followed, and a CX segment with reason-code
MISCOLORED SHOULD be sent to the LTP sender with the Cancellation
sequence beginning with the CX marker.
Otherwise, the LTP receiver enters the Receive Red-Part state
(RCV_RP) or the Receive Green-Part state (RCV_GP) depending on
whether the segment received was red or green, respectively.
In the RCV_RP state, a check is made of the nature of the received
red DS. If the segment was a regular red data segment, the receiver
LTP just returns to the DS_REC state. For red data segments marked
also as CP and as CP & EORP, a responding RS segment is queued for
transmission to the sender following either the internal procedure
Retransmit RS (Section 6.8) or Send Reception Report (Section 6.11)
depending on whether the CP segment was a retransmission (an RS
segment corresponding to the checkpoint serial number in the CP
segment was previously issued) or not, respectively. The LTP
receiver then returns to the DS_REC state. If the block transmission
was fully red and the segment was marked as CP, EORP, and EOB, the
LTP receiver enters the Wait-for-Red-Part-Reception state
(WAIT_RP_REC). In all cases, the internal procedure Start RS Timer
(Section 6.3) is followed upon receiving link state cues indicating
the beginning of transmission of the RS segments.
In the RCV_GP state, if the received green data segment was not
marked EOB, the LTP receiver returns to the DS_REC state. Otherwise,
it enters the WAIT_RP_REC state to receive the red-part of the block
fully.
A previously set RS timer may expire and interrupt the LTP receiver
while in the DS_REC, RCV_RP, RCV_GP, or WAIT_RP_REC state. If so,
the internal procedure Retransmit RS (Section 6.8) is followed as
illustrated in the states beginning at the RX marker (shown in the
second part of the diagram) before returning to the interrupted
state:
- A check is made here to see if the retransmission limit set by
the network management has been exceeded in the number of RSs
sent in the session. If so, a CR segment with reason-code RLEXC
SHOULD be sent to the LTP sender and the sequence indicated by
the CX marker is followed. Otherwise, the RS segment is queued
for retransmission and the associated RS timer is started
following the internal procedure Start RS Timer (Section 6.3)
upon receiving a link state cue indicating the beginning of its
transmission.
Ramadas, et al. Experimental [Page 46]
^L
RFC 5326 LTP - Specification September 2008
The LTP receiver may also receive RA segments from the sender in
response to the RS segments sent while in the DS_REC state. If so,
then the RS timer corresponding to the report serial number mentioned
in the RA segment is canceled following the internal procedure Stop
RS Timer (Section 6.14).
The LTP receiver stays in the WAIT_RP_REC state until the entire red-
part of the block is received, and moves to the CLOSED state upon
full red-part reception. In this state, a check is made upon
reception of every red-part data segment to see if it is at a block
offset higher than any green-part data segment received. If so, the
internal procedure Handle Miscolored Segment (Section 6.21) is
invoked and the sequence of state transitions beginning with the CX
marker is followed; a CX segment with reason-code MISCOLORED SHOULD
be sent to the LTP sender with the Cancellation sequence beginning
with the CX marker.
Note that if there were no red data segments received in the session
yet, including the case where the session was indeed fully green or
the pathological case where the entire red-part of the block gets
lost but at least the green data segment marked EOB is received (the
LTP receiver has no indication of whether the session had a red-part
transmission), the LTP receiver assumes the "RP rcvd. fully"
condition to be true and moves to the CLOSED state from the
WAIT_RP_REC state.
In the WAIT_RP_REC state, the LTP receiver may receive the
retransmitted red data segments. Upon receiving red data segments
marked CP, it queues the responding RS segment for transmission based
on either internal procedure Retransmit RS (Section 6.8) or Send
Reception Report (Section 6.11) depending on whether the CP was found
to be a retransmission or not, respectively. The internal procedure
Start RS Timer is invoked upon receiving a link state cue indicating
the beginning of transmission of the RS segment. If an RA segment is
received, the RS timer corresponding to the report segment mentioned
is canceled and the LTP receiver stays in the state until the entire
red-part is received.
In the sequence of state transitions beginning at the CX marker, the
CR segment with the given reason-code (depending on how the sequence
is entered) is queued for transmission, and the CR timer is started
upon reception of the link state cue indicating actual transmission
following the internal procedure Start Cancel Timer (Section 6.15).
If the CAR segment is received from the LTP sender, the LTP receiver
returns to the CLOSED state (via the Cncld marker) following the
internal procedure Stop Cancel Timer (Section 6.18). If the CR timer
expires asynchronously, the internal procedure Retransmit
Cancellation Segment (Section 6.16) is followed:
Ramadas, et al. Experimental [Page 47]
^L
RFC 5326 LTP - Specification September 2008
- A check is made to see if the retransmission limit set by the
network management for the number of CR segments per session has
been exceeded. If so, the LTP receiver returns to the CLOSED
state following the Cncld marker. Otherwise, a CR segment is
scheduled for retransmission with the CR timer being started
following the internal procedure Start Cancel Timer (Section
6.15) upon reception of a link state cue indicating actual
transmission.
The LTP receiver might also receive a retransmitted CS segment at the
CLOSED state (either if the CAS segment previously transmitted was
lost or if the CS timer expired prematurely at the LTP sender). In
such a case, the CAS is scheduled for retransmission.
9. Security Considerations
9.1. Denial of Service Considerations
Implementers SHOULD consider the likelihood of the following Denial
of Service (DoS) attacks:
- A fake Cx could be inserted, thus bringing down a session.
- Various acknowledgment segments (RA, RS, etc.) could be deleted,
causing timers to expire, and having the potential to disable
communication altogether if done with a knowledge of the
communications schedule. This could be achieved either by
mounting a DoS attack on a lower-layer service in order to
prevent it from sending an acknowledgment segment, or by simply
jamming the transmission (all of which are more likely for
terrestrial applications of LTP).
- An attacker might also corrupt some bits, which is tantamount to
deleting that segment.
- An attacker may flood an LTP engine with segments for the
internal operations queue and prevent transmission of legitimate
data segments.
Ramadas, et al. Experimental [Page 48]
^L
RFC 5326 LTP - Specification September 2008
- An attacker could attempt to fill up the storage in an engine by
sending many large messages to it. In terrestrial LTP
applications, this may be much more serious since spotting the
additional traffic may not be possible from any network
management point.
If any of the above DoS attacks is likely, then one or more of the
following anti-DoS mechanisms ought to be employed:
- Session numbers SHOULD be partly random making it harder to
insert valid segments.
- An engine that suspects that either it or its peer is under DoS
attack could frequently checkpoint its data segments (if it were
the sender) or send asynchronous RSs (if it were the receiver),
thus eliciting an earlier response from its peer or timing out
earlier due to the failure of an attacker to respond.
- Serial numbers (checkpoint serial numbers, report serial
numbers) MUST begin each session anew using random numbers
rather than from 0.
- The authentication header [LTPEXT].
9.2. Replay Handling
The following algorithm is given as an example of how an LTP
implementation MAY handle replays.
1. On receipt of an LTP segment, check against a cache for replay.
If this is a replay segment and if a pre-cooked response is
available (stored from the last time this segment was processed),
then send the pre-cooked response. If there is no pre-cooked
response, then silently drop the inbound segment. This can all be
done without attempting to decode the buffer.
2. If the inbound segment does not decode correctly, then silently
drop the segment. If the segment decodes properly, then add its
hash to the replay cache and return a handle to the entry.
3. For those cases where a pre-cooked response should be stored,
store the response using the handle received from the previous
step. These cases include:
(a) when the inbound packet is a CP segment, the RS segment sent
in response gets stored as pre-cooked,
Ramadas, et al. Experimental [Page 49]
^L
RFC 5326 LTP - Specification September 2008
(b) when the Incoming packet is an RS segment, the RA segment is
stored as pre-cooked, and
(c) when the incoming packet is a Cx segment, the CAx segment sent
in response gets stored pre-cooked.
4. Occasionally clean out the replay cache -- how frequently this
happens is an implementation issue.
The downside of this algorithm is that receiving a totally bogus
segment still results in a replay cache search and attempted LTP
decode operation. It is not clear that it is possible to do much
better though, since all an attacker would have to do to get past the
replay cache would be to tweak a single bit in the inbound segment
each time, which is certainly cheaper than the hash+lookup+decode
combination, though also certainly more expensive than simply sending
the same octets many times.
The benefit of doing this is that implementers no longer need to
analyze many bugs/attacks based on replaying packets, which in
combination with the use of LTP authentication should defeat many
attempted DoS attacks.
9.3. Implementation Considerations
SDNV
Implementations SHOULD make sanity checks on SDNV length fields
and SHOULD check that no SDNV field is too long when compared with
the overall segment length.
Implementations SHOULD check that SDNV values are within suitable
ranges where possible.
Byte ranges
Various report and other segments contain offset and length
fields. Implementations MUST ensure that these are consistent and
sane.
Randomness
Various fields in LTP (e.g., serial numbers) MUST be initialized
using random values. Good sources of randomness that are not
easily guessable SHOULD be used [ESC05]. The collision of random
values is subject to the birthday paradox, which means that a
collision is likely after roughly the square root of the space has
been seen (e.g., 2^16 in the case of a 32-bit random value).
Ramadas, et al. Experimental [Page 50]
^L
RFC 5326 LTP - Specification September 2008
Implementers MUST ensure that they use sufficiently long random
values so that the birthday paradox doesn't cause a problem in
their environment.
10. IANA Considerations
10.1. UDP Port Number for LTP
The UDP port number 1113 with the name "ltp-deepspace" has been
reserved for LTP deployments. An LTP implementation may be
implemented to operate over UDP datagrams using this port number for
study and testing over the Internet.
10.2. LTP Extension Tag Registry
The IANA has created and now maintains a registry for known LTP
Extension Tags (as indicated in Section 3.1). The registry has been
populated using the initial values given in Section 3.1 above. IANA
may assign LTP Extension Tag values from the range 0x02-0xAF
(inclusive) using the Specification Required rule [GUIDE]. The
specification concerned can be an RFC (whether Standards Track,
Experimental, or Informational), or a specification from any other
standards development organization recognized by IANA or with a
liaison with the IESG, specifically including CCSDS
(http://www.ccsds.org/). Any use of Reserved values (0xB0-0xBF
inclusive) requires an update this specification.
11. Acknowledgments
Many thanks to Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian
Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss for
their thoughts on this protocol and its role in Delay-Tolerant
Networking architecture.
Part of the research described in this document was carried out at
the Jet Propulsion Laboratory, California Institute of Technology,
under a contract with the National Aeronautics and Space
Administration. This work was performed under DOD Contract DAA-B07-
00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870;
and NASA Contract NAS7-1407.
Thanks are also due to Shawn Ostermann, Hans Kruse, Dovel Myers, and
Jayram Deshpande at Ohio University for their suggestions and advice
in making various design decisions. This work was done when
Manikantan Ramadas was a graduate student at the EECS Dept., Ohio
University, in the Internetworking Research Group Laboratory.
Ramadas, et al. Experimental [Page 51]
^L
RFC 5326 LTP - Specification September 2008
Part of this work was carried out at Trinity College Dublin as part
of the SeNDT contract funded by Enterprise Ireland's research
innovation fund.
12. References
12.1. Normative References
[B97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[GUIDE] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, May
2008.
[LTPMTV] Burleigh, S., Ramadas, M., and S. Farrell,"Licklider
Transmission Protocol - Motivation", RFC 5325, September
2008.
[LTPEXT] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider
Transmission Protocol - Security Extensions", RFC 5327,
September 2008.
12.2. Informative References
[ASN1] Abstract Syntax Notation One (ASN.1). ASN.1 Encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER), and Distinguished Encoding Rules
(DER). ITU-T Rec. X.690 (2002) | ISO/IEC 8825-1:2002.
[BP] Scott, K. and S. Burleigh, "Bundle Protocol Specification",
RFC 5050, November 2007.
[DTN] K. Fall, "A Delay-Tolerant Network Architecture for
Challenged Internets", In Proceedings of ACM SIGCOMM 2003,
Karlsruhe, Germany, Aug 2003.
[ESC05] D. Eastlake, J. Schiller and S. Crockerr, "Randomness
Recommendations for Security", RFC 4086, June 2005.
[SACK] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, "TCP
Selective Acknowledgement Options", RFC 2018, October 1996.
Ramadas, et al. Experimental [Page 52]
^L
RFC 5326 LTP - Specification September 2008
Authors' Addresses
Manikantan Ramadas
ISRO Telemetry Tracking and Command Network (ISTRAC)
Indian Space Research Organization (ISRO)
Plot # 12 & 13, 3rd Main, 2nd Phase
Peenya Industrial Area
Bangalore 560097
India
Telephone: +91 80 2364 2602
EMail: mramadas@gmail.com
Scott C. Burleigh
Jet Propulsion Laboratory
4800 Oak Grove Drive
M/S: 301-490
Pasadena, CA 91109-8099
Telephone: +1 (818) 393-3353
Fax: +1 (818) 354-1075
EMail: Scott.Burleigh@jpl.nasa.gov
Stephen Farrell
Computer Science Department
Trinity College Dublin
Ireland
Telephone: +353-1-896-1761
EMail: stephen.farrell@cs.tcd.ie
Ramadas, et al. Experimental [Page 53]
^L
RFC 5326 LTP - Specification September 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78 and at http://www.rfc-editor.org/copyright.html,
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, THE IETF TRUST 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 BCP 78 and BCP 79.
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
http://www.ietf.org/ipr.
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.
Ramadas, et al. Experimental [Page 54]
^L
|