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
|
Network Working Group V. Cerf
Request for Comments: 4838 Google/Jet Propulsion Laboratory
Category: Informational S. Burleigh
A. Hooke
L. Torgerson
NASA/Jet Propulsion Laboratory
R. Durst
K. Scott
The MITRE Corporation
K. Fall
Intel Corporation
H. Weiss
SPARTA, Inc.
April 2007
Delay-Tolerant Networking Architecture
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
IESG Note
This RFC is a product of the Internet Research Task Force and is not
a candidate for any level of Internet Standard. The IRTF publishes
the results of Internet-related research and development activities.
These results might not be suitable for deployment on the public
Internet.
Abstract
This document describes an architecture for delay-tolerant and
disruption-tolerant networks, and is an evolution of the architecture
originally designed for the Interplanetary Internet, a communication
system envisioned to provide Internet-like services across
interplanetary distances in support of deep space exploration. This
document describes an architecture that addresses a variety of
problems with internetworks having operational and performance
characteristics that make conventional (Internet-like) networking
approaches either unworkable or impractical. We define a message-
oriented overlay that exists above the transport (or other) layers of
Cerf, et al. Informational [Page 1]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
the networks it interconnects. The document presents a motivation
for the architecture, an architectural overview, review of state
management required for its operation, and a discussion of
application design issues. This document represents the consensus of
the IRTF DTN research group and has been widely reviewed by that
group.
Table of Contents
1. Introduction ....................................................3
2. Why an Architecture for Delay-Tolerant Networking? ..............4
3. DTN Architectural Description ...................................5
3.1. Virtual Message Switching Using Store-and-Forward
Operation ..................................................5
3.2. Nodes and Endpoints ........................................7
3.3. Endpoint Identifiers (EIDs) and Registrations ..............8
3.4. Anycast and Multicast .....................................10
3.5. Priority Classes ..........................................10
3.6. Postal-Style Delivery Options and Administrative Records ..11
3.7. Primary Bundle Fields .....................................15
3.8. Routing and Forwarding ....................................16
3.9. Fragmentation and Reassembly ..............................18
3.10. Reliability and Custody Transfer .........................19
3.11. DTN Support for Proxies and Application Layer Gateways ...21
3.12. Timestamps and Time Synchronization ......................22
3.13. Congestion and Flow Control at the Bundle Layer ..........22
3.14. Security .................................................23
4. State Management Considerations ................................25
4.1. Application Registration State ............................25
4.2. Custody Transfer State ....................................26
4.3. Bundle Routing and Forwarding State .......................26
4.4. Security-Related State ....................................27
4.5. Policy and Configuration State ............................27
5. Application Structuring Issues .................................28
6. Convergence Layer Considerations for Use of Underlying
Protocols ......................................................28
7. Summary ........................................................29
8. Security Considerations ........................................29
9. IANA Considerations ............................................30
10. Normative References ..........................................30
11. Informative References ........................................30
12. Acknowledgments ...............................................32
Cerf, et al. Informational [Page 2]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
1. Introduction
This document describes an architecture for delay and disruption-
tolerant interoperable networking (DTN). The architecture embraces
the concepts of occasionally-connected networks that may suffer from
frequent partitions and that may be comprised of more than one
divergent set of protocols or protocol families. The basis for this
architecture lies with that of the Interplanetary Internet, which
focused primarily on the issue of deep space communication in high-
delay environments. We expect the DTN architecture described here to
be utilized in various operational environments, including those
subject to disruption and disconnection and those with high-delay;
the case of deep space is one specialized example of these, and is
being pursued as a specialization of this architecture (See [IPN01]
and [SB03] for more details).
Other networks to which we believe this architecture applies include
sensor-based networks using scheduled intermittent connectivity,
terrestrial wireless networks that cannot ordinarily maintain end-to-
end connectivity, satellite networks with moderate delays and
periodic connectivity, and underwater acoustic networks with moderate
delays and frequent interruptions due to environmental factors. A
DTN tutorial [FW03], aimed at introducing DTN and the types of
networks for which it is designed, is available to introduce new
readers to the fundamental concepts and motivation. More technical
descriptions may be found in [KF03], [JFP04], [JDPF05], and [WJMF05].
We define an end-to-end message-oriented overlay called the "bundle
layer" that exists at a layer above the transport (or other) layers
of the networks on which it is hosted and below applications.
Devices implementing the bundle layer are called DTN nodes. The
bundle layer forms an overlay that employs persistent storage to help
combat network interruption. It includes a hop-by-hop transfer of
reliable delivery responsibility and optional end-to-end
acknowledgement. It also includes a number of diagnostic and
management features. For interoperability, it uses a flexible naming
scheme (based on Uniform Resource Identifiers [RFC3986]) capable of
encapsulating different naming and addressing schemes in the same
overall naming syntax. It also has a basic security model,
optionally enabled, aimed at protecting infrastructure from
unauthorized use.
The bundle layer provides functionality similar to the internet layer
of gateways described in the original ARPANET/Internet designs
[CK74]. It differs from ARPANET gateways, however, because it is
layer-agnostic and is focused on virtual message forwarding rather
than packet switching. However, both generally provide
interoperability between underlying protocols specific to one
Cerf, et al. Informational [Page 3]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
environment and those protocols specific to another, and both provide
a store-and-forward forwarding service (with the bundle layer
employing persistent storage for its store and forward function).
In a sense, the DTN architecture provides a common method for
interconnecting heterogeneous gateways or proxies that employ store-
and-forward message routing to overcome communication disruptions.
It provides services similar to electronic mail, but with enhanced
naming, routing, and security capabilities. Nodes unable to support
the full capabilities required by this architecture may be supported
by application-layer proxies acting as DTN applications.
2. Why an Architecture for Delay-Tolerant Networking?
Our motivation for pursuing an architecture for delay tolerant
networking stems from several factors. These factors are summarized
below; much more detail on their rationale can be explored in [SB03],
[KF03], and [DFS02].
The existing Internet protocols do not work well for some
environments, due to some fundamental assumptions built into the
Internet architecture:
- that an end-to-end path between source and destination exists for
the duration of a communication session
- (for reliable communication) that retransmissions based on timely
and stable feedback from data receivers is an effective means for
repairing errors
- that end-to-end loss is relatively small
- that all routers and end stations support the TCP/IP protocols
- that applications need not worry about communication performance
- that endpoint-based security mechanisms are sufficient for meeting
most security concerns
- that packet switching is the most appropriate abstraction for
interoperability and performance
- that selecting a single route between sender and receiver is
sufficient for achieving acceptable communication performance
The DTN architecture is conceived to relax most of these assumptions,
based on a number of design principles that are summarized here (and
further discussed in [KF03]):
Cerf, et al. Informational [Page 4]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
- Use variable-length (possibly long) messages (not streams or
limited-sized packets) as the communication abstraction to help
enhance the ability of the network to make good scheduling/path
selection decisions when possible.
- Use a naming syntax that supports a wide range of naming and
addressing conventions to enhance interoperability.
- Use storage within the network to support store-and-forward
operation over multiple paths, and over potentially long timescales
(i.e., to support operation in environments where many and/or no
end-to-end paths may ever exist); do not require end-to-end
reliability.
- Provide security mechanisms that protect the infrastructure from
unauthorized use by discarding traffic as quickly as possible.
- Provide coarse-grained classes of service, delivery options, and a
way to express the useful lifetime of data to allow the network to
better deliver data in serving the needs of applications.
The use of the bundle layer is guided not only by its own design
principles, but also by a few application design principles:
- Applications should minimize the number of round-trip exchanges.
- Applications should cope with restarts after failure while network
transactions remain pending.
- Applications should inform the network of the useful life and
relative importance of data to be delivered.
These issues are discussed in further detail in Section 5.
3. DTN Architectural Description
The previous section summarized the design principles that guide the
definition of the DTN architecture. This section presents a
description of the major features of the architecture resulting from
design decisions guided by the aforementioned design principles.
3.1. Virtual Message Switching Using Store-and-Forward Operation
A DTN-enabled application sends messages of arbitrary length, also
called Application Data Units or ADUs [CT90], which are subject to
any implementation limitations. The relative order of ADUs might not
be preserved. ADUs are typically sent by and delivered to
Cerf, et al. Informational [Page 5]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
applications in complete units, although a system interface that
behaves differently is not precluded.
ADUs are transformed by the bundle layer into one or more protocol
data units called "bundles", which are forwarded by DTN nodes.
Bundles have a defined format containing two or more "blocks" of
data. Each block may contain either application data or other
information used to deliver the containing bundle to its
destination(s). Blocks serve the purpose of holding information
typically found in the header or payload portion of protocol data
units in other protocol architectures. The term "block" is used
instead of "header" because blocks may not appear at the beginning of
a bundle due to particular processing requirements (e.g., digital
signatures).
Bundles may be split up ("fragmented") into multiple constituent
bundles (also called "fragments" or "bundle fragments") during
transmission. Fragments are themselves bundles, and may be further
fragmented. Two or more fragments may be reassembled anywhere in the
network, forming a new bundle.
Bundle sources and destinations are identified by (variable-length)
Endpoint Identifiers (EIDs, described below), which identify the
original sender and final destination(s) of bundles, respectively.
Bundles also contain a "report-to" EID used when special operations
are requested to direct diagnostic output to an arbitrary entity
(e.g., other than the source). An EID may refer to one or more DTN
nodes (i.e., for multicast destinations or "report-to" destinations).
While IP networks are based on "store-and-forward" operation, there
is an assumption that the "storing" will not persist for more than a
modest amount of time, on the order of the queuing and transmission
delay. In contrast, the DTN architecture does not expect that
network links are always available or reliable, and instead expects
that nodes may choose to store bundles for some time. We anticipate
that most DTN nodes will use some form of persistent storage for this
-- disk, flash memory, etc. -- and that stored bundles will survive
system restarts.
Bundles contain an originating timestamp, useful life indicator, a
class of service designator, and a length. This information provides
bundle-layer routing with a priori knowledge of the size and
performance requirements of requested data transfers. When there is
a significant amount of queuing that can occur in the network (as is
the case in the DTN version of store-and-forward), the advantage
provided by knowing this information may be significant for making
scheduling and path selection decisions [JFP04]. An alternative
abstraction (i.e., of stream-based delivery based on packets) would
Cerf, et al. Informational [Page 6]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
make such scheduling much more difficult. Although packets provide
some of the same benefits as bundles, larger aggregates provide a way
for the network to apply scheduling and buffer management to units of
data that are more useful to applications.
An essential element of the bundle-based style of forwarding is that
bundles have a place to wait in a queue until a communication
opportunity ("contact") is available. This highlights the following
assumptions:
1. that storage is available and well-distributed throughout the
network,
2. that storage is sufficiently persistent and robust to store
bundles until forwarding can occur, and
3. (implicitly) that this "store-and-forward" model is a better
choice than attempting to effect continuous connectivity or other
alternatives.
For a network to effectively support the DTN architecture, these
assumptions must be considered and must be found to hold. Even so,
the inclusion of long-term storage as a fundamental aspect of the DTN
architecture poses new problems, especially with respect to
congestion management and denial-of-service mitigation. Node storage
in essence represents a new resource that must be managed and
protected. Much of the research in DTN revolves around exploring
these issues. Congestion is discussed in Section 3.13, and security
mechanisms, including methods for DTN nodes to protect themselves
from handling unauthorized traffic from other nodes, are discussed in
[DTNSEC] and [DTNSOV].
3.2. Nodes and Endpoints
A DTN node (or simply "node" in this document) is an engine for
sending and receiving bundles -- an implementation of the bundle
layer. Applications utilize DTN nodes to send or receive ADUs
carried in bundles (applications also use DTN nodes when acting as
report-to destinations for diagnostic information carried in
bundles). Nodes may be members of groups called "DTN endpoints". A
DTN endpoint is therefore a set of DTN nodes. A bundle is considered
to have been successfully delivered to a DTN endpoint when some
minimum subset of the nodes in the endpoint has received the bundle
without error. This subset is called the "minimum reception group"
(MRG) of the endpoint. The MRG of an endpoint may refer to one node
(unicast), one of a group of nodes (anycast), or all of a group of
nodes (multicast and broadcast). A single node may be in the MRG of
multiple endpoints.
Cerf, et al. Informational [Page 7]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
3.3. Endpoint Identifiers (EIDs) and Registrations
An Endpoint Identifier (EID) is a name, expressed using the general
syntax of URIs (see below), that identifies a DTN endpoint. Using an
EID, a node is able to determine the MRG of the DTN endpoint named by
the EID. Each node is also required to have at least one EID that
uniquely identifies it.
Applications send ADUs destined for an EID, and may arrange for ADUs
sent to a particular EID to be delivered to them. Depending on the
construction of the EID being used (see below), there may be a
provision for wildcarding some portion of an EID, which is often
useful for diagnostic and routing purposes.
An application's desire to receive ADUs destined for a particular EID
is called a "registration", and in general is maintained persistently
by a DTN node. This allows application registration information to
survive application and operating system restarts.
An application's attempt to establish a registration is not
guaranteed to succeed. For example, an application could request to
register itself to receive ADUs by specifying an Endpoint ID that is
uninterpretable or unavailable to the DTN node servicing the request.
Such requests are likely to fail.
3.3.1. URI Schemes
Each Endpoint ID is expressed syntactically as a Uniform Resource
Identifier (URI) [RFC3986]. The URI syntax has been designed as a
way to express names or addresses for a wide range of purposes, and
is therefore useful for constructing names for DTN endpoints.
In URI terminology, each URI begins with a scheme name. The scheme
name is an element of the set of globally-managed scheme names
maintained by IANA [ISCHEMES]. Lexically following the scheme name
in a URI is a series of characters constrained by the syntax defined
by the scheme. This portion of the URI is called the scheme-specific
part (SSP), and can be quite general. (See, as one example, the URI
scheme for SNMP [RFC4088]). Note that scheme-specific syntactical
and semantic restrictions may be more constraining than the basic
rules of RFC 3986. Section 3.1 of RFC 3986 provides guidance on the
syntax of scheme names.
URI schemes are a key concept in the DTN architecture, and evolved
from an earlier concept called regions, which were tied more closely
to assumptions of the network topology. Using URIs, significant
flexibility is attained in the structuring of EIDs. They might, for
example, be constructed based on DNS names, or might look like
Cerf, et al. Informational [Page 8]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
"expressions of interest" or forms of database-like queries as in a
directed diffusion-routed network [IGE00] or in intentional naming
[WSBL99]. As names, EIDs are not required to be related to routing
or topological organization. Such a relationship is not prohibited,
however, and in some environments using EIDs this way may be
advantageous.
A single EID may refer to an endpoint containing more than one DTN
node, as suggested above. It is the responsibility of a scheme
designer to define how to interpret the SSP of an EID so as to
determine whether it refers to a unicast, multicast, or anycast set
of nodes. See Section 3.4 for more details.
URIs are constructed based on rules specified in RFC 3986, using the
US-ASCII character set. However, note this excerpt from RFC 3986,
Section 1.2.1, on dealing with characters that cannot be represented
by US-ASCII: "Percent-encoded octets (Section 2.1) may be used
within a URI to represent characters outside the range of the US-
ASCII coded character set if this representation is allowed by the
scheme or by the protocol element in which the URI is referenced.
Such a definition should specify the character encoding used to map
those characters to octets prior to being percent-encoded for the
URI".
3.3.2. Late Binding
Binding means interpreting the SSP of an EID for the purpose of
carrying an associated message towards a destination. For example,
binding might require mapping an EID to a next-hop EID or to a lower-
layer address for transmission. "Late binding" means that the
binding of a bundle's destination to a particular set of destination
identifiers or addresses does not necessarily happen at the bundle
source. Because the destination EID is potentially re-interpreted at
each hop, the binding may occur at the source, during transit, or
possibly at the destination(s). This contrasts with the name-to-
address binding of Internet communications where a DNS lookup at the
source fixes the IP address of the destination node before data is
sent. Such a circumstance would be considered "early binding"
because the name-to-address translation is performed prior to data
being sent into the network.
In a frequently-disconnected network, late binding may be
advantageous because the transit time of a message may exceed the
validity time of a binding, making binding at the source impossible
or invalid. Furthermore, use of name-based routing with late binding
may reduce the amount of administrative (mapping) information that
Cerf, et al. Informational [Page 9]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
must propagate through the network, and may also limit the scope of
mapping synchronization requirements to a local topological
neighborhood where changes are made.
3.4. Anycast and Multicast
As mentioned above, an EID may refer to an endpoint containing one or
more DTN nodes. When referring to a group of size greater than one,
the delivery semantics may be of either the anycast or multicast
variety (broadcast is considered to be of the multicast variety).
For anycast group delivery, a bundle is delivered to one node among a
group of potentially many nodes, and for multicast delivery it is
intended to be delivered to all of them, subject to the normal DTN
class of service and maximum useful lifetime semantics.
Multicast group delivery in a DTN presents an unfamiliar issue with
respect to group membership. In relatively low-delay networks, such
as the Internet, nodes may be considered to be part of the group if
they have expressed interest to join it "recently". In a DTN,
however, nodes may wish to receive data sent to a group during an
interval of time earlier than when they are actually able to receive
it [ZAZ05]. More precisely, an application expresses its desire to
receive data sent to EID e at time t. Prior to this, during the
interval [t0, t1], t > t1, data may have been generated for group e.
For the application to receive any of this data, the data must be
available a potentially long time after senders have ceased sending
to the group. Thus, the data may need to be stored within the
network in order to support temporal group semantics of this kind.
How to design and implement this remains a research issue, as it is
likely to be at least as hard as problems related to reliable
multicast.
3.5. Priority Classes
The DTN architecture offers *relative* measures of priority (low,
medium, high) for delivering ADUs. These priorities differentiate
traffic based upon an application's desire to affect the delivery
urgency for ADUs, and are carried in bundle blocks generated by the
bundle layer based on information specified by the application.
The (U.S. or similar) Postal Service provides a strong metaphor for
the priority classes offered by the forwarding abstraction offered by
the DTN architecture. Traffic is generally not interactive and is
often one-way. There are generally no strong guarantees of timely
delivery, yet there are some forms of class of service, reliability,
and security.
Cerf, et al. Informational [Page 10]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
We have defined three relative priority classes to date. These
priority classes typically imply some relative scheduling
prioritization among bundles in queue at a sender:
- Bulk - Bulk bundles are shipped on a "least effort" basis. No
bundles of this class will be shipped until all bundles of other
classes bound for the same destination and originating from the
same source have been shipped.
- Normal - Normal-class bundles are shipped prior to any bulk-class
bundles and are otherwise the same as bulk bundles.
- Expedited - Expedited bundles, in general, are shipped prior to
bundles of other classes and are otherwise the same.
Applications specify their requested priority class and data lifetime
(see below) for each ADU they send. This information, coupled with
policy applied at DTN nodes that select how messages are forwarded
and which routing algorithms are in use, affects the overall
likelihood and timeliness of ADU delivery.
The priority class of a bundle is only required to relate to other
bundles from the same source. This means that a high priority bundle
from one source may not be delivered faster (or with some other
superior quality of service) than a medium priority bundle from a
different source. It does mean that a high priority bundle from one
source will be handled preferentially to a lower priority bundle sent
from the same source.
Depending on a particular DTN node's forwarding/scheduling policy,
priority may or may not be enforced across different sources. That
is, in some DTN nodes, expedited bundles might always be sent prior
to any bulk bundles, irrespective of source. Many variations are
possible.
3.6. Postal-Style Delivery Options and Administrative Records
Continuing with the postal analogy, the DTN architecture supports
several delivery options that may be selected by an application when
it requests the transmission of an ADU. In addition, the
architecture defines two types of administrative records: "status
reports" and "signals". These records are bundles that provide
information about the delivery of other bundles, and are used in
conjunction with the delivery options.
Cerf, et al. Informational [Page 11]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
3.6.1. Delivery Options
We have defined eight delivery options. Applications sending an ADU
(the "subject ADU") may request any combination of the following,
which are carried in each of the bundles produced ("sent bundles") by
the bundle layer resulting from the application's request to send the
subject ADU:
- Custody Transfer Requested - requests sent bundles be delivered
with enhanced reliability using custody transfer procedures. Sent
bundles will be transmitted by the bundle layer using reliable
transfer protocols (if available), and the responsibility for
reliable delivery of the bundle to its destination(s) may move
among one or more "custodians" in the network. This capability is
described in more detail in Section 3.10.
- Source Node Custody Acceptance Required - requires the source DTN
node to provide custody transfer for the sent bundles. If custody
transfer is not available at the source when this delivery option
is requested, the requested transmission fails. This provides a
means for applications to insist that the source DTN node take
custody of the sent bundles (e.g., by storing them in persistent
storage).
- Report When Bundle Delivered - requests a (single) Bundle Delivery
Status Report be generated when the subject ADU is delivered to its
intended recipient(s). This request is also known as "return-
receipt".
- Report When Bundle Acknowledged by Application - requests an
Acknowledgement Status Report be generated when the subject ADU is
acknowledged by a receiving application. This only happens by
action of the receiving application, and differs from the Bundle
Delivery Status Report. It is intended for cases where the
application may be acting as a form of application layer gateway
and wishes to indicate the status of a protocol operation external
to DTN back to the requesting source. See Section 11 for more
details.
- Report When Bundle Received - requests a Bundle Reception Status
Report be generated when each sent bundle arrives at a DTN node.
This is designed primarily for diagnostic purposes.
- Report When Bundle Custody Accepted - requests a Custody
Acceptance Status Report be generated when each sent bundle has
been accepted using custody transfer. This is designed primarily
for diagnostic purposes.
Cerf, et al. Informational [Page 12]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
- Report When Bundle Forwarded - requests a Bundle Forwarding Status
Report be generated when each sent bundle departs a DTN node after
forwarding. This is designed primarily for diagnostic purposes.
- Report When Bundle Deleted - requests a Bundle Deletion Status
Report be generated when each sent bundle is deleted at a DTN node.
This is designed primarily for diagnostic purposes.
The first four delivery options are designed for ordinary use by
applications. The last four are designed primarily for diagnostic
purposes and their use may be restricted or limited in environments
subject to congestion or attack.
If the security procedures defined in [DTNSEC] are also enabled, then
three additional delivery options become available:
- Confidentiality Required - requires the subject ADU be made secret
from parties other than the source and the members of the
destination EID.
- Authentication Required - requires all non-mutable fields in the
bundle blocks of the sent bundles (i.e., those which do not change
as the bundle is forwarded) be made strongly verifiable (i.e.,
cryptographically strong). This protects several fields, including
the source and destination EIDs and the bundle's data. See Section
3.7 and [BSPEC] for more details.
- Error Detection Required - requires modifications to the non-
mutable fields of each sent bundle be made detectable with high
probability at each destination.
3.6.2. Administrative Records: Bundle Status Reports and Custody
Signals
Administrative records are used to report status information or error
conditions related to the bundle layer. There are two types of
administrative records defined: bundle status reports (BSRs) and
custody signals. Administrative records correspond (approximately)
to messages in the ICMP protocol in IP [RFC792]. In ICMP, however,
messages are returned to the source. In DTN, they are instead
directed to the report-to EID for BSRs and the EID of the current
custodian for custody signals, which might differ from the source's
EID. Administrative records are sent as bundles with a source EID
set to one of the EIDs associated with the DTN node generating the
administrative record. In some cases, arrival of a single bundle or
bundle fragment may elicit multiple administrative records (e.g., in
the case where a bundle is replicated for multicast forwarding).
Cerf, et al. Informational [Page 13]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
The following BSRs are currently defined (also see [BSPEC] for more
details):
- Bundle Reception - sent when a bundle arrives at a DTN node.
Generation of this message may be limited by local policy.
- Custody Acceptance - sent when a node has accepted custody of a
bundle with the Custody Transfer Requested option set. Generation
of this message may be limited by local policy.
- Bundle Forwarded - sent when a bundle containing a Report When
Bundle Forwarded option departs from a DTN node after having been
forwarded. Generation of this message may be limited by local
policy.
- Bundle Deletion - sent from a DTN node when a bundle containing a
Report When Bundle Deleted option is discarded. This can happen
for several reasons, such as expiration. Generation of this
message may be limited by local policy but is required in cases
where the deletion is performed by a bundle's current custodian.
- Bundle Delivery - sent from a final recipient's (destination) node
when a complete ADU comprising sent bundles containing Report When
Bundle Delivered options is consumed by an application.
- Acknowledged by application - sent from a final recipient's
(destination) node when a complete ADU comprising sent bundles
containing Application Acknowledgment options has been processed by
an application. This generally involves specific action on the
receiving application's part.
In addition to the status reports, the custody signal is currently
defined to indicate the status of a custody transfer. These are sent
to the current-custodian EID contained in an arriving bundle:
- Custody Signal - indicates that custody has been successfully
transferred. This signal appears as a Boolean indicator, and may
therefore indicate either a successful or a failed custody transfer
attempt.
Administrative records must reference a received bundle. This is
accomplished by a method for uniquely identifying bundles based on a
transmission timestamp and sequence number discussed in Section 3.12.
Cerf, et al. Informational [Page 14]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
3.7. Primary Bundle Fields
The bundles carried between and among DTN nodes obey a standard
bundle protocol specified in [BSPEC]. Here we provide an overview of
most of the fields carried with every bundle. The protocol is
designed with a mandatory primary block, an optional payload block
(which contains the ADU data itself), and a set of optional extension
blocks. Blocks may be cascaded in a way similar to extension headers
in IPv6. The following selected fields are all present in the
primary block, and therefore are present for every bundle and
fragment:
- Creation Timestamp - a concatenation of the bundle's creation time
and a monotonically increasing sequence number such that the
creation timestamp is guaranteed to be unique for each ADU
originating from the same source. The creation timestamp is based
on the time-of-day an application requested an ADU to be sent (not
when the corresponding bundle(s) are sent into the network). DTN
nodes are assumed to have a basic time synchronization capability
(see Section 3.12).
- Lifespan - the time-of-day at which the message is no longer
useful. If a bundle is stored in the network (including the
source's DTN node) when its lifespan is reached, it may be
discarded. The lifespan of a bundle is expressed as an offset
relative to its creation time.
- Class of Service Flags - indicates the delivery options and
priority class for the bundle. Priority classes may be one of
bulk, normal, or expedited. See Section 3.6.1.
- Source EID - EID of the source (the first sender).
- Destination EID - EID of the destination (the final intended
recipient(s)).
- Report-To Endpoint ID - an EID identifying where reports (return-
receipt, route-tracing functions) should be sent. This may or may
not identify the same endpoint as the Source EID.
- Custodian EID - EID of the current custodian of a bundle (if any).
The payload block indicates information about the contained payload
(e.g., its length) and the payload itself. In addition to the fields
found in the primary and payload blocks, each bundle may have fields
in additional blocks carried with each bundle. See [BSPEC] for
additional details.
Cerf, et al. Informational [Page 15]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
3.8. Routing and Forwarding
The DTN architecture provides a framework for routing and forwarding
at the bundle layer for unicast, anycast, and multicast messages.
Because nodes in a DTN network might be interconnected using more
than one type of underlying network technology, a DTN network is best
described abstractly using a *multigraph* (a graph where vertices may
be interconnected with more than one edge). Edges in this graph are,
in general, time-varying with respect to their delay and capacity and
directional because of the possibility of one-way connectivity. When
an edge has zero capacity, it is considered to not be connected.
Because edges in a DTN graph may have significant delay, it is
important to distinguish where time is measured when expressing an
edge's capacity or delay. We adopt the convention of expressing
capacity and delay as functions of time where time is measured at the
point where data is inserted into a network edge. For example,
consider an edge having capacity C(t) and delay D(t) at time t. If B
bits are placed in this edge at time t, they completely arrive by
time t + D(t) + (1/C(t))*B. We assume C(t) and D(t) do not change
significantly during the interval [t, t+D(t)+(1/C(t))*B].
Because edges may vary between positive and zero capacity, it is
possible to describe a period of time (interval) during which the
capacity is strictly positive, and the delay and capacity can be
considered to be constant [AF03]. This period of time is called a
"contact". In addition, the product of the capacity and the interval
is known as a contact's "volume". If contacts and their volumes are
known ahead of time, intelligent routing and forwarding decisions can
be made (optimally for small networks) [JFP04]. Optimally using a
contact's volume, however, requires the ability to divide large ADUs
and bundles into smaller routable units. This is provided by DTN
fragmentation (see Section 3.9).
When delivery paths through a DTN graph are lossy or contact
intervals and volumes are not known precisely ahead of time, routing
computations become especially challenging. How to handle these
situations is an active area of work in the (emerging) research area
of delay tolerant networking.
3.8.1. Types of Contacts
Contacts typically fall into one of several categories, based largely
on the predictability of their performance characteristics and
whether some action is required to bring them into existence. To
date, the following major types of contacts have been defined:
Cerf, et al. Informational [Page 16]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
Persistent Contacts
Persistent contacts are always available (i.e., no connection-
initiation action is required to instantiate a persistent
contact). An 'always-on' Internet connection such as a DSL or
Cable Modem connection would be a representative of this class.
On-Demand Contacts
On-Demand contacts require some action in order to instantiate,
but then function as persistent contacts until terminated. A
dial-up connection is an example of an On-Demand contact (at
least, from the viewpoint of the dialer; it may be viewed as an
Opportunistic Contact, below, from the viewpoint of the dial-up
service provider).
Intermittent - Scheduled Contacts
A scheduled contact is an agreement to establish a contact at a
particular time, for a particular duration. An example of a
scheduled contact is a link with a low-earth orbiting satellite.
A node's list of contacts with the satellite can be constructed
from the satellite's schedule of view times, capacities, and
latencies. Note that for networks with substantial delays, the
notion of the "particular time" is delay-dependent. For example,
a single scheduled contact between Earth and Mars would not be at
the same instant in each location, but would instead be offset by
the (non-negligible) propagation delay.
Intermittent - Opportunistic Contacts
Opportunistic contacts are not scheduled, but rather present
themselves unexpectedly. For example, an unscheduled aircraft
flying overhead and beaconing, advertising its availability for
communication, would present an opportunistic contact. Another
type of opportunistic contact might be via an infrared or
Bluetooth communication link between a personal digital assistant
(PDA) and a kiosk in an airport concourse. The opportunistic
contact begins as the PDA is brought near the kiosk, lasting an
undetermined amount of time (i.e., until the link is lost or
terminated).
Intermittent - Predicted Contacts
Predicted contacts are based on no fixed schedule, but rather are
predictions of likely contact times and durations based on a
history of previously observed contacts or some other information.
Given a great enough confidence in a predicted contact, routes may
Cerf, et al. Informational [Page 17]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
be chosen based on this information. This is an active research
area, and a few approaches having been proposed [LFC05].
3.9. Fragmentation and Reassembly
DTN fragmentation and reassembly are designed to improve the
efficiency of bundle transfers by ensuring that contact volumes are
fully utilized and by avoiding retransmission of partially-forwarded
bundles. There are two forms of DTN fragmentation/reassembly:
Proactive Fragmentation
A DTN node may divide a block of application data into multiple
smaller blocks and transmit each such block as an independent
bundle. In this case, the *final destination(s)* are responsible
for extracting the smaller blocks from incoming bundles and
reassembling them into the original larger bundle and, ultimately,
ADU. This approach is called proactive fragmentation because it
is used primarily when contact volumes are known (or predicted) in
advance.
Reactive Fragmentation
DTN nodes sharing an edge in the DTN graph may fragment a bundle
cooperatively when a bundle is only partially transferred. In
this case, the receiving bundle layer modifies the incoming bundle
to indicate it is a fragment, and forwards it normally. The
previous- hop sender may learn (via convergence-layer protocols,
see Section 6) that only a portion of the bundle was delivered to
the next hop, and send the remaining portion(s) when subsequent
contacts become available (possibly to different next-hops if
routing changes). This is called reactive fragmentation because
the fragmentation process occurs after an attempted transmission
has taken place.
As an example, consider a ground station G, and two store-and-
forward satellites S1 and S2, in opposite low-earth orbit. While
G is transmitting a large bundle to S1, a reliable transport layer
protocol below the bundle layer at each indicates the transmission
has terminated, but that half the transfer has completed
successfully. In this case, G can form a smaller bundle fragment
consisting of the second half of the original bundle and forward
it to S2 when available. In addition, S1 (now out of range of G)
can form a new bundle consisting of the first half of the original
bundle and forward it to whatever next hop(s) it deems
appropriate.
Cerf, et al. Informational [Page 18]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
The reactive fragmentation capability is not required to be available
in every DTN implementation, as it requires a certain level of
support from underlying protocols that may not be present, and
presents significant challenges with respect to handling digital
signatures and authentication codes on messages. When a signed
message is only partially received, most message authentication codes
will fail. When DTN security is present and enabled, it may
therefore be necessary to proactively fragment large bundles into
smaller units that are more convenient for digital signatures.
Even if reactive fragmentation is not present in an implementation,
the ability to reassemble fragments at a destination is required in
order to support DTN fragmentation. Furthermore, for contacts with
volumes that are small compared to typical bundle sizes, some
incremental delivery approach must be used (e.g., checkpoint/restart)
to prevent data delivery livelock. Reactive fragmentation is one
such approach, but other protocol layers could potentially handle
this issue as well.
3.10. Reliability and Custody Transfer
The most basic service provided by the bundle layer is
unacknowledged, prioritized (but not guaranteed) unicast message
delivery. It also provides two options for enhancing delivery
reliability: end-to-end acknowledgments and custody transfer.
Applications wishing to implement their own end-to-end message
reliability mechanisms are free to utilize the acknowledgment. The
custody transfer feature of the DTN architecture only specifies a
coarse-grained retransmission capability, described next.
Transmission of bundles with the Custody Transfer Requested option
specified generally involves moving the responsibility for reliable
delivery of an ADU's bundles among different DTN nodes in the
network. For unicast delivery, this will typically involve moving
bundles "closer" (in terms of some routing metric) to their ultimate
destination(s), and retransmitting when necessary. The nodes
receiving these bundles along the way (and agreeing to accept the
reliable delivery responsibility) are called "custodians". The
movement of a bundle (and its delivery responsibility) from one node
to another is called a "custody transfer". It is analogous to a
database commit transaction [FHM03]. The exact meaning and design of
custody transfer for multicast and anycast delivery remains to be
fully explored.
Custody transfer allows the source to delegate retransmission
responsibility and recover its retransmission-related resources
relatively soon after sending a bundle (on the order of the minimum
round-trip time to the first bundle hop(s)). Not all nodes in a DTN
Cerf, et al. Informational [Page 19]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
are required by the DTN architecture to accept custody transfers, so
it is not a true 'hop-by-hop' mechanism. For example, some nodes may
have sufficient storage resources to sometimes act as custodians, but
may elect to not offer such services when congested or running low on
power.
The existence of custodians can alter the way DTN routing is
performed. In some circumstances, it may be beneficial to move a
bundle to a custodian as quickly as possible even if the custodian is
further away (in terms of distance, time or some routing metric) from
the bundle's final destination(s) than some other reachable node.
Designing a system with this capability involves constructing more
than one routing graph, and is an area of continued research.
Custody transfer in DTN not only provides a method for tracking
bundles that require special handling and identifying DTN nodes that
participate in custody transfer, it also provides a (weak) mechanism
for enhancing the reliability of message delivery. Generally
speaking, custody transfer relies on underlying reliable delivery
protocols of the networks that it operates over to provide the
primary means of reliable transfer from one bundle node to the next
(set). However, when custody transfer is requested, the bundle layer
provides an additional coarse-grained timeout and retransmission
mechanism and an accompanying (bundle-layer) custodian-to-custodian
acknowledgment signaling mechanism. When an application does *not*
request custody transfer, this bundle layer timeout and
retransmission mechanism is typically not employed, and successful
bundle layer delivery depends solely on the reliability mechanisms of
the underlying protocols.
When a node accepts custody for a bundle that contains the Custody
Transfer Requested option, a Custody Transfer Accepted Signal is sent
by the bundle layer to the Current Custodian EID contained in the
primary bundle block. In addition, the Current Custodian EID is
updated to contain one of the forwarding node's (unicast) EIDs before
the bundle is forwarded.
When an application requests an ADU to be delivered with custody
transfer, the request is advisory. In some circumstances, a source
of a bundle for which custody transfer has been requested may not be
able to provide this service. In such circumstances, the subject
bundle may traverse multiple DTN nodes before it obtains a custodian.
Bundles in this condition are specially marked with their Current
Custodian EID field set to a null endpoint. In cases where
applications wish to require the source to take custody of the
bundle, they may supply the Source Node Custody Acceptance Required
Cerf, et al. Informational [Page 20]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
delivery option. This may be useful to applications that desire a
continuous "chain" of custody or that wish to exit after being
ensured their data is safely held in a custodian.
In a DTN network where one or more custodian-to-custodian hops are
strictly one directional (and cannot be reversed), the DTN custody
transfer mechanism will be affected over such hops due to the lack of
any way to receive a custody signal (or any other information) back
across the path, resulting in the expiration of the bundle at the
ingress to the one-way hop. This situation does not necessarily mean
the bundle has been lost; nodes on the other side of the hop may
continue to transfer custody, and the bundle may be delivered
successfully to its destination(s). However, in this circumstance a
source that has requested to receive expiration BSRs for this bundle
will receive an expiration report for the bundle, and possibly
conclude (incorrectly) that the bundle has been discarded and not
delivered. Although this problem cannot be fully solved in this
situation, a mechanism is provided to help ameliorate the seemingly
incorrect information that may be reported when the bundle expires
after having been transferred over a one-way hop. This is
accomplished by the node at the ingress to the one-way hop reporting
the existence of a known one-way path using a variant of a bundle
status report. These types of reports are provided if the subject
bundle requests the report using the 'Report When Bundle Forwarded'
delivery option.
3.11. DTN Support for Proxies and Application Layer Gateways
One of the aims of DTN is to provide a common method for
interconnecting application layer gateways and proxies. In cases
where existing Internet applications can be made to tolerate delays,
local proxies can be constructed to benefit from the existing
communication capabilities provided by DTN [S05, T02]. Making such
proxies compatible with DTN reduces the burden on the proxy author
from being concerned with how to implement routing and reliability
management and allows existing TCP/IP-based applications to operate
unmodified over a DTN-based network.
When DTN is used to provide a form of tunnel encapsulation for other
protocols, it can be used in constructing overlay networks comprised
of application layer gateways. The application acknowledgment
capability is designed for such circumstances. This provides a
common way for remote application layer gateways to signal the
success or failure of non-DTN protocol operations initiated as a
result of receiving DTN ADUs. Without this capability, such
indicators would have to be implemented by applications themselves in
non-standard ways.
Cerf, et al. Informational [Page 21]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
3.12. Timestamps and Time Synchronization
The DTN architecture depends on time synchronization among DTN nodes
(supported by external, non-DTN protocols) for four primary purposes:
bundle and fragment identification, routing with scheduled or
predicted contacts, bundle expiration time computations, and
application registration expiration.
Bundle identification and expiration are supported by placing a
creation timestamp and an explicit expiration field (expressed in
seconds after the source timestamp) in each bundle. The origination
timestamps on arriving bundles are made available to consuming
applications in ADUs they receive by some system interface function.
Each set of bundles corresponding to an ADU is required to contain a
timestamp unique to the sender's EID. The EID, timestamp, and data
offset/length information together uniquely identify a bundle.
Unique bundle identification is used for a number of purposes,
including custody transfer and reassembly of bundle fragments.
Time is also used in conjunction with application registrations.
When an application expresses its desire to receive ADUs destined for
a particular EID, this registration is only maintained for a finite
period of time, and may be specified by the application. For
multicast registrations, an application may also specify a time range
or "interest interval" for its registration. In this case, traffic
sent to the specified EID any time during the specified interval will
eventually be delivered to the application (unless such traffic has
expired due to the expiration time provided by the application at the
source or some other reason prevents such delivery).
3.13. Congestion and Flow Control at the Bundle Layer
The subject of congestion control and flow control at the bundle
layer is one on which the authors of this document have not yet
reached complete consensus. We have unresolved concerns about the
efficiency and efficacy of congestion and flow control schemes
implemented across long and/or highly variable delay environments,
especially with the custody transfer mechanism that may require nodes
to retain bundles for long periods of time.
For the purposes of this document, we define "flow control" as a
means of assuring that the average rate at which a sending node
transmits data to a receiving node does not exceed the average rate
at which the receiving node is prepared to receive data from that
sender. (Note that this is a generalized notion of flow control,
rather than one that applies only to end-to-end communication.) We
define "congestion control" as a means of assuring that the aggregate
rate at which all traffic sources inject data into a network does not
Cerf, et al. Informational [Page 22]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
exceed the maximum aggregate rate at which the network can deliver
data to destination nodes over time. If flow control is propagated
backward from congested nodes toward traffic sources, then the flow
control mechanism can be used as at least a partial solution to the
problem of congestion as well.
DTN flow control decisions must be made within the bundle layer
itself based on information about resources (in this case, primarily
persistent storage) available within the bundle node. When storage
resources become scarce, a DTN node has only a certain degree of
freedom in handling the situation. It can always discard bundles
which have expired -- an activity DTN nodes should perform regularly
in any case. If it ordinarily is willing to accept custody for
bundles, it can cease doing so. If storage resources are available
elsewhere in the network, it may be able to make use of them in some
way for bundle storage. It can also discard bundles which have not
expired but for which it has not accepted custody. A node must avoid
discarding bundles for which it has accepted custody, and do so only
as a last resort. Determining when a node should engage in or cease
to engage in custody transfers is a resource allocation and
scheduling problem of current research interest.
In addition to the bundle layer mechanisms described above, a DTN
node may be able to avail itself of support from lower-layer
protocols in affecting its own resource utilization. For example, a
DTN node receiving a bundle using TCP/IP might intentionally slow
down its receiving rate by performing read operations less frequently
in order to reduce its offered load. This is possible because TCP
provides its own flow control, so reducing the application data
consumption rate could effectively implement a form of hop-by-hop
flow control. Unfortunately, it may also lead to head-of-line
blocking issues, depending on the nature of bundle multiplexing
within a TCP connection. A protocol with more relaxed ordering
constraints (e.g. SCTP [RFC2960]) might be preferable in such
circumstances.
Congestion control is an ongoing research topic.
3.14. Security
The possibility of severe resource scarcity in some delay-tolerant
networks dictates that some form of authentication and access control
to the network itself is required in many circumstances. It is not
acceptable for an unauthorized user to flood the network with traffic
easily, possibly denying service to authorized users. In many cases
it is also not acceptable for unauthorized traffic to be forwarded
over certain network links at all. This is especially true for
exotic, mission-critical links. In light of these considerations,
Cerf, et al. Informational [Page 23]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
several goals are established for the security component of the DTN
architecture:
- Promptly prevent unauthorized applications from having their data
carried through or stored in the DTN.
- Prevent unauthorized applications from asserting control over the
DTN infrastructure.
- Prevent otherwise authorized applications from sending bundles at a
rate or class of service for which they lack permission.
- Promptly discard bundles that are damaged or improperly modified in
transit.
- Promptly detect and de-authorize compromised entities.
Many existing authentication and access control protocols designed
for operation in low-delay, connected environments may not perform
well in DTNs. In particular, updating access control lists and
revoking ("blacklisting") credentials may be especially difficult.
Also, approaches that require frequent access to centralized servers
to complete an authentication or authorization transaction are not
attractive. The consequences of these difficulties include delays in
the onset of communication, delays in detecting and recovering from
system compromise, and delays in completing transactions due to
inappropriate access control or authentication settings.
To help satisfy these security requirements in light of the
challenges, the DTN architecture adopts a standard but optionally
deployed security architecture [DTNSEC] that utilizes hop-by-hop and
end-to-end authentication and integrity mechanisms. The purpose of
using both approaches is to be able to handle access control for data
forwarding and storage separately from application-layer data
integrity. While the end-to-end mechanism provides authentication
for a principal such as a user (of which there may be many), the hop-
by-hop mechanism is intended to authenticate DTN nodes as legitimate
transceivers of bundles to each-other. Note that it is conceivable
to construct a DTN in which only a subset of the nodes participate in
the security mechanisms, resulting in a secure DTN overlay existing
atop an insecure DTN overlay. This idea is relatively new and is
still being explored.
In accordance with the goals listed above, DTN nodes discard traffic
as early as possible if authentication or access control checks fail.
This approach meets the goals of removing unwanted traffic from being
forwarded over specific high-value links, but also has the associated
benefit of making denial-of-service attacks considerably harder to
Cerf, et al. Informational [Page 24]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
mount more generally, as compared with conventional Internet routers.
However, the obvious cost for this capability is potentially larger
computation and credential storage overhead required at DTN nodes.
For more detailed information on DTN security provisions, refer to
[DTNSEC] and [DTNSOV].
4. State Management Considerations
An important aspect of any networking architecture is its management
of state. This section describes the state managed at the bundle
layer and discusses how it is established and removed.
4.1. Application Registration State
In long/variable delay environments, an asynchronous application
interface seems most appropriate. Such interfaces typically include
methods for applications to register callback actions when certain
triggering events occur (e.g., when ADUs arrive). These
registrations create state information called application
registration state.
Application registration state is typically created by explicit
request of the application, and is removed by a separate explicit
request, but may also be removed by an application-specified timer
(it is thus "firm" state). In most cases, there must be a provision
for retaining this state across application and operating system
termination/restart conditions because a client/server bundle round-
trip time may exceed the requesting application's execution time (or
hosting system's uptime). In cases where applications are not
automatically restarted but application registration state remains
persistent, a method must be provided to indicate to the system what
action to perform when the triggering event occurs (e.g., restarting
some application, ignoring the event, etc.).
To initiate a registration and thereby establish application
registration state, an application specifies an Endpoint ID for which
it wishes to receive ADUs, along with an optional time value
indicating how long the registration should remain active. This
operation is somewhat analogous to the bind() operation in the common
sockets API.
For registrations to groups (i.e., joins), a time interval may also
be specified. The time interval refers to the range of origination
times of ADUs sent to the specified EID. See Section 3.4 above for
more details.
Cerf, et al. Informational [Page 25]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
4.2. Custody Transfer State
Custody transfer state includes information required to keep account
of bundles for which a node has taken custody, as well as the
protocol state related to transferring custody for one or more of
them. The accounting-related state is created when a bundle is
received. Custody transfer retransmission state is created when a
transfer of custody is initiated by forwarding a bundle with the
custody transfer requested delivery option specified. Retransmission
state and accounting state may be released upon receipt of one or
more Custody Transfer Succeeded signals, indicating custody has been
moved. In addition, the bundle's expiration time (possibly mitigated
by local policy) provides an upper bound on the time when this state
is purged from the system in the event that it is not purged
explicitly due to receipt of a signal.
4.3. Bundle Routing and Forwarding State
As with the Internet architecture, we distinguish between routing and
forwarding. Routing refers to the execution of a (possibly
distributed) algorithm for computing routing paths according to some
objective function (see [JFP04], for example). Forwarding refers to
the act of moving a bundle from one DTN node to another. Routing
makes use of routing state (the RIB, or routing information base),
while forwarding makes use of state derived from routing, and is
maintained as forwarding state (the FIB, or forwarding information
base). The structure of the FIB and the rules for maintaining it are
implementation choices. In some DTNs, exchange of information used
to update state in the RIB may take place on network paths distinct
from those where exchange of application data takes place.
The maintenance of state in the RIB is dependent on the type of
routing algorithm being used. A routing algorithm may consider
requested class of service and the location of potential custodians
(for custody transfer, see section 3.10), and this information will
tend to increase the size of the RIB. The separation between FIB and
RIB is not required by this document, as these are implementation
details to be decided by system implementers. The choice of routing
algorithms is still under study.
Bundles may occupy queues in nodes for a considerable amount of time.
For unicast or anycast delivery, the amount of time is likely to be
the interval between when a bundle arrives at a node and when it can
be forwarded to its next hop. For multicast delivery of bundles,
this could be significantly longer, up to a bundle's expiration time.
This situation occurs when multicast delivery is utilized in such a
way that nodes joining a group can obtain information previously sent
to the group. In such cases, some nodes may act as "archivers" that
Cerf, et al. Informational [Page 26]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
provide copies of bundles to new participants that have already been
delivered to other participants.
4.4. Security-Related State
The DTN security approach described in [DTNSEC], when used, requires
maintenance of state in all DTN nodes that use it. All such nodes
are required to store their own private information (including their
own policy and authentication material) and a block of information
used to verify credentials. Furthermore, in most cases, DTN nodes
will cache some public information (and possibly the credentials) of
their next-hop (bundle) neighbors. All cached information has
expiration times, and nodes are responsible for acquiring and
distributing updates of public information and credentials prior to
the expiration of the old set (in order to avoid a disruption in
network service).
In addition to basic end-to-end and hop-by-hop authentication, access
control may be used in a DTN by one or more mechanisms such as
capabilities or access control lists (ACLs). ACLs would represent
another block of state present in any node that wishes to enforce
security policy. ACLs are typically initialized at node
configuration time and may be updated dynamically by DTN bundles or
by some out of band technique. Capabilities or credentials may be
revoked, requiring the maintenance of a revocation list ("black
list", another form of state) to check for invalid authentication
material that has already been distributed.
Some DTNs may implement security boundaries enforced by selected
nodes in the network, where end-to-end credentials may be checked in
addition to checking the hop-by-hop credentials. (Doing so may
require routing to be adjusted to ensure all bundles comprising each
ADU pass through these points.) Public information used to verify
end-to-end authentication will typically be cached at these points.
4.5. Policy and Configuration State
DTN nodes will contain some amount of configuration and policy
information. Such information may alter the behavior of bundle
forwarding. Examples of policy state include the types of
cryptographic algorithms and access control procedures to use if DTN
security is employed, whether nodes may become custodians, what types
of convergence layer (see Section 6) and routing protocols are in
use, how bundles of differing priorities should be scheduled, where
and for how long bundles and other data is stored, what status
reports may be generated or at what rate, etc.
Cerf, et al. Informational [Page 27]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
5. Application Structuring Issues
DTN bundle delivery is intended to operate in a delay-tolerant
fashion over a broad range of network types. This does not mean
there *must* be large delays in the network; it means there *may* be
very significant delays (including extended periods of disconnection
between sender and intended recipient(s)). The DTN protocols are
delay tolerant, so applications using them must also be delay
tolerant in order to operate effectively in environments subject to
significant delay or disruption.
The communication primitives provided by the DTN architecture are
based on asynchronous, message-oriented communication which differs
from conversational request/response communication. In general,
applications should attempt to include enough information in an ADU
so that it may be treated as an independent unit of work by the
network and receiver(s). The goal is to minimize synchronous
interchanges between applications that are separated by a network
characterized by long and possibly highly variable delays. A single
file transfer request message, for example, might include
authentication information, file location information, and requested
file operation (thus "bundling" this information together).
Comparing this style of operation to a classic FTP transfer, one sees
that the bundled model can complete in one round trip, whereas an FTP
file "put" operation can take as many as eight round trips to get to
a point where file data can flow [DFS02].
Delay-tolerant applications must consider additional factors beyond
the conversational implications of long delay paths. For example, an
application may terminate (voluntarily or not) between the time it
sends a message and the time it expects a response. If this
possibility has been anticipated, the application can be "re-
instantiated" with state information saved in persistent storage.
This is an implementation issue, but also an application design
consideration.
Some consideration of delay-tolerant application design can result in
applications that work reasonably well in low-delay environments, and
that do not suffer extraordinarily in high or highly-variable delay
environments.
6. Convergence Layer Considerations for Use of Underlying Protocols
Implementation experience with the DTN architecture has revealed an
important architectural construct and interface for DTN nodes
[DBFJHP04]. Not all underlying protocols in different protocol
families provide the same exact functionality, so some additional
adaptation or augmentation on a per-protocol or per-protocol-family
Cerf, et al. Informational [Page 28]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
basis may be required. This adaptation is accomplished by a set of
convergence layers placed between the bundle layer and underlying
protocols. The convergence layers manage the protocol-specific
details of interfacing with particular underlying protocols and
present a consistent interface to the bundle layer.
The complexity of one convergence layer may vary substantially from
another, depending on the type of underlying protocol it adapts. For
example, a TCP/IP convergence layer for use in the Internet might
only have to add message boundaries to TCP streams, whereas a
convergence layer for some network where no reliable transport
protocol exists might be considerably more complex (e.g., it might
have to implement reliability, fragmentation, flow-control, etc.) if
reliable delivery is to be offered to the bundle layer.
As convergence layers implement protocols above and beyond the basic
bundle protocol specified in [BSPEC], they will be defined in their
own documents (in a fashion similar to the way encapsulations for IP
datagrams are specified on a per-underlying-protocol basis, such as
in RFC 894 [RFC894]).
7. Summary
The DTN architecture addresses many of the problems of heterogeneous
networks that must operate in environments subject to long delays and
discontinuous end-to-end connectivity. It is based on asynchronous
messaging and uses postal mail as a model of service classes and
delivery semantics. It accommodates many different forms of
connectivity, including scheduled, predicted, and opportunistically
connected delivery paths. It introduces a novel approach to end-to-
end reliability across frequently partitioned and unreliable
networks. It also proposes a model for securing the network
infrastructure against unauthorized access.
It is our belief that this architecture is applicable to many
different types of challenged environments.
8. Security Considerations
Security is an integral concern for the design of the Delay Tolerant
Network Architecture, but its use is optional. Sections 3.6.1, 3.14,
and 4.4 of this document present some factors to consider for
securing the DTN architecture, but separate documents [DTNSOV] and
[DTNSEC] define the security architecture in much more detail.
Cerf, et al. Informational [Page 29]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
9. IANA Considerations
This document specifies the architecture for Delay Tolerant
Networking, which uses Internet-standard URIs for its Endpoint
Identifiers. URIs intended for use with DTN should be compliant with
the guidelines given in [RFC3986].
10. Normative References
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
11. Informative References
[IPN01] InterPlaNetary Internet Project, Internet Society IPN
Special Interest Group, http://www.ipnsig.org.
[SB03] S. Burleigh, et al., "Delay-Tolerant Networking - An
Approach to Interplanetary Internet", IEEE Communications
Magazine, July 2003.
[FW03] F. Warthman, "Delay-Tolerant Networks (DTNs): A Tutorial
v1.1", Wartham Associates, 2003. Available from
http://www.dtnrg.org.
[KF03] K. Fall, "A Delay-Tolerant Network Architecture for
Challenged Internets", Proceedings SIGCOMM, Aug 2003.
[JFP04] S. Jain, K. Fall, R. Patra, "Routing in a Delay Tolerant
Network", Proceedings SIGCOMM, Aug/Sep 2004.
[DFS02] R. Durst, P. Feighery, K. Scott, "Why not use the
Standard Internet Suite for the Interplanetary
Internet?", MITRE White Paper, 2002. Available from
http://www.ipnsig.org/reports/TCP_IP.pdf.
[CK74] V. Cerf, R. Kahn, "A Protocol for Packet Network
Intercommunication", IEEE Trans. on Comm., COM-22(5), May
1974.
[IGE00] C. Intanagonwiwat, R. Govindan, D. Estrin, "Directed
Diffusion: A Scalable and Robust Communication Paradigm
for Sensor Networks", Proceedings MobiCOM, Aug 2000.
Cerf, et al. Informational [Page 30]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
[WSBL99] W. Adjie-Winoto, E. Schwartz, H. Balakrishnan, J. Lilley,
"The Design and Implementation of an Intentional Naming
System", Proc. 17th ACM SOSP, Kiawah Island, SC, Dec.
1999.
[CT90] D. Clark, D. Tennenhouse, "Architectural Considerations
for a New Generation of Protocols", Proceedings SIGCOMM,
1990.
[ISCHEMES] IANA, Uniform Resource Identifer (URI) Schemes,
http://www.iana.org/assignments/uri-schemes.html.
[JDPF05] S. Jain, M. Demmer, R. Patra, K. Fall, "Using Redundancy
to Cope with Failures in a Delay Tolerant Network",
Proceedings SIGCOMM, 2005.
[WJMF05] Y. Wang, S. Jain, M. Martonosi, K. Fall, "Erasure Coding
Based Routing in Opportunistic Networks", Proceedings
SIGCOMM Workshop on Delay Tolerant Networks, 2005.
[ZAZ05] W. Zhao, M. Ammar, E. Zegura, "Multicast in Delay
Tolerant Networks", Proceedings SIGCOMM Workshop on Delay
Tolerant Networks, 2005.
[LFC05] J. Leguay, T. Friedman, V. Conan, "DTN Routing in a
Mobility Pattern Space", Proceedings SIGCOMM Workshop on
Delay Tolerant Networks, 2005.
[AF03] J. Alonso, K. Fall, "A Linear Programming Formulation of
Flows over Time with Piecewise Constant Capacity and
Transit Times", Intel Research Technical Report IRB-TR-
03-007, June 2003.
[FHM03] K. Fall, W. Hong, S. Madden, "Custody Transfer for
Reliable Delivery in Delay Tolerant Networks", Intel
Research Technical Report IRB-TR-03-030, July 2003.
[BSPEC] K. Scott, S. Burleigh, "Bundle Protocol Specification",
Work in Progress, December 2006.
[DTNSEC] S. Symington, S. Farrell, H. Weiss, "Bundle Security
Protocol Specification", Work in Progress, October 2006.
[DTNSOV] S. Farrell, S. Symington, H. Weiss, "Delay-Tolerant
Networking Security Overview", Work in Progress, October
2006.
Cerf, et al. Informational [Page 31]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
[DBFJHP04] M. Demmer, E. Brewer, K. Fall, S. Jain, M. Ho, R. Patra,
"Implementing Delay Tolerant Networking", Intel Research
Technical Report IRB-TR-04-020, Dec. 2004.
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC894] Hornig, C., "A Standard for the Transmission of IP
Datagrams over Ethernet Networks", STD 41, RFC 894, April
1 1984.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC4088] Black, D., McCloghrie, K., and J. Schoenwaelder, "Uniform
Resource Identifier (URI) Scheme for the Simple Network
Management Protocol (SNMP)", RFC 4088, June 2005.
[S05] K. Scott, "Disruption Tolerant Networking Proxies for
On-the-Move Tactical Networks", Proc. MILCOM 2005
(unclassified track), Oct. 2005.
[T02] W. Thies, et al., "Searching the World Wide Web in Low-
Connectivity Communities", Proc. WWW Conference (Global
Community track), May 2002.
12. Acknowledgments
John Wroclawski, David Mills, Greg Miller, James P. G. Sterbenz, Joe
Touch, Steven Low, Lloyd Wood, Robert Braden, Deborah Estrin, Stephen
Farrell, Melissa Ho, Ting Liu, Mike Demmer, Jakob Ericsson, Susan
Symington, Andrei Gurtov, Avri Doria, Tom Henderson, Mark Allman,
Michael Welzl, and Craig Partridge all contributed useful thoughts
and criticisms to versions of this document. We are grateful for
their time and participation.
This work was performed in part under DOD Contract DAA-B07-00-CC201,
DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; and NASA
Contract NAS7-1407.
Cerf, et al. Informational [Page 32]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
Authors' Addresses
Dr. Vinton G. Cerf
Google Corporation
Suite 384
13800 Coppermine Rd.
Herndon, VA 20171
Phone: +1 (703) 234-1823
Fax: +1 (703) 848-0727
EMail: vint@google.com
Scott C. Burleigh
Jet Propulsion Laboratory
4800 Oak Grove Drive
M/S: 179-206
Pasadena, CA 91109-8099
Phone: +1 (818) 393-3353
Fax: +1 (818) 354-1075
EMail: Scott.Burleigh@jpl.nasa.gov
Robert C. Durst
The MITRE Corporation
7515 Colshire Blvd., M/S H440
McLean, VA 22102
Phone: +1 (703) 983-7535
Fax: +1 (703) 983-7142
EMail: durst@mitre.org
Dr. Kevin Fall
Intel Research, Berkeley
2150 Shattuck Ave., #1300
Berkeley, CA 94704
Phone: +1 (510) 495-3014
Fax: +1 (510) 495-3049
EMail: kfall@intel.com
Adrian J. Hooke
Jet Propulsion Laboratory
4800 Oak Grove Drive
M/S: 303-400
Pasadena, CA 91109-8099
Phone: +1 (818) 354-3063
Fax: +1 (818) 393-3575
EMail: Adrian.Hooke@jpl.nasa.gov
Cerf, et al. Informational [Page 33]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
Dr. Keith L. Scott
The MITRE Corporation
7515 Colshire Blvd., M/S H440
McLean, VA 22102
Phone: +1 (703) 983-6547
Fax: +1 (703) 983-7142
EMail: kscott@mitre.org
Leigh Torgerson
Jet Propulsion Laboratory
4800 Oak Grove Drive
M/S: 238-412
Pasadena, CA 91109-8099
Phone: +1 (818) 393-0695
Fax: +1 (818) 354-6825
EMail: ltorgerson@jpl.nasa.gov
Howard S. Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
Phone: +1 (410) 872-1515 x201
Fax: +1 (410) 872-8079
EMail: howard.weiss@sparta.com
Please refer comments to dtn-interest@mailman.dtnrg.org. The Delay
Tolerant Networking Research Group (DTNRG) web site is located at
http://www.dtnrg.org.
Cerf, et al. Informational [Page 34]
^L
RFC 4838 Delay-Tolerant Networking Architecture April 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Cerf, et al. Informational [Page 35]
^L
|