This file is indexed.

/usr/share/ion/tutorial.html is in ion-doc 3.2.1+dfsg-1.1.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

   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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xml:lang="en" xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>Documentation</title>
    <!-- base href="https://ion.ocp.ohiou.edu/drupal" -->
    <link type="text/css" rel="stylesheet" href="tutorial_files/print.html">
      </head><body>
        
    <div id="node-12" class="section-1">
  <h1 class="book-heading">Documentation</h1>
  <p>The
documentation for Ion is broken up into several sections that deal with
the general installation and configuration of Ion. The design
documentation for Ion is available <a href="https://ion.ocp.ohiou.edu/drupal/sites/default/files/ION.pdf">here</a>.</p>  <div id="node-15" class="section-2">
  <h1 class="book-heading">Release Notes</h1>

<h1>Release Notes for ION 2.3.0</h1>

<p>
December 5, 2010
</p>

<h1>GENERAL</h1>

<p>
The ION (interplanetary overlay network) software is a suite of communication
protocol implementations designed to support mission operation communications
across an end-to-end interplanetary network, which might include on-board
(flight) subnets, in-situ planetary or lunar networks, proximity links, deep
space links, and terrestrial internets.  Included in the ION softwarex
distribution are the following packages:
</p>

<ul>
<li>ici (interplanetary communication infrastructure), a set of libraries
  that provide flight-software-compatible support for functions on which
  the other packages rely, such as dynamic memory management, non-volatile
  storage management, and inter-task communication via shared memory.
  The ici libraries are designed to make the porting of IPN software to
  multiple operating systems - Linux, VxWorks, Solaris, etc. - as easy as
  possible. Ici now includes zco (zero-copy object), a library that 
  minimizes the copying of application data as it is encapsulated in 
  multiple layers of protocol structure while traversing the protocol
  stack.
<p></p>
</li>
<li>bp (bundle protocol), an implementation of the Delay-Tolerant
  Networking (DTN) architecture's Bundle Protocol.
<p></p>
</li>
<li>dgr (datagram retransmission), a UDP reliability system that
  implements congestion control and is designed for relatively high
  performance.
<p></p>
</li>
<li>ltp (licklider transmission protocol), a DTN convergence layer for
  reliable transmission over links characterized by long or highly
  variable delay.
<p></p>
</li>
<li>ams - an implementation of the CCSDS Asynchronous Message Service.
<p></p>
</li>
<li>cfdp - a class-1 (Unacknowledged) implementation of the CCSDS File
  Delivery Protocol.
</li>
</ul>

<p>
Features included:
</p>

<ul>
<li>cgr - Contract graph routing: a method of dynamic routing designed for
  space based applications of ION, but still usable for terrestrial
  applications. It computes routes using scheduled communication and deals
  with time-varying network topology.
<p></p>
</li>
<li>brs - Bundle relay service: provides interconnectivity between networks
  that do not allow servers (those behind NAT for example). For more
  information, check man brsscla and man brsccla.
</li>
</ul>

<h1>NOTES ON RELEASE 2.3.0</h1>

<ul>
<li>Modified administrative startup commands to block until startup is complete,
  rather than return immediately even if the node hasn't been fully initialized.
<p></p>
</li>
<li>Fixed a bug which truncated dtn-scheme bundle source EIDs.
<p></p>
</li>
<li>Modified some tests (1000.loopback) to run compiled objects instead of shell
  scripts.  This eliminates the need for shell scripting and allows automated
  tests to function on platforms without shell access.
<p></p>
</li>
<li>Combined similar test configurations to use the shared /configs directory.
  This will provide a standard set of updated configurations.
<p></p>
</li>
<li>Test suite has been modified to support multiple test sets.  Creating a
  text file in the tests directory containing a list of tests is all that
  is needed to create a test set.
  Examples: make test-all ; make test-branch ; make test-&lt;anything&gt;
<p></p>
</li>
<li>Added "limbo" queue to support suspension and resumption.  This allows the
  node to handle unexpected convergence layer failure as opposed to scheduled
  or static contact termination.
<p></p>
</li>
<li>Code scrub of DGR.
<p></p>
</li>
<li>Added bping, bpchat, and bpstats2 utilities.
<p></p>
</li>
<li>Custody transfer is now optional in both bptrace and bpsend.
<p></p>
</li>
<li>Added feature for "convergence-layer stewardship"; CL's can initiate
  reforwarding of bundles on transmission failure without explicit
  bundle-layer custodianship.
<p></p>
</li>
<li>Enhanced LTP's udplso with a transmission rate limiter.
<p></p>
</li>
<li>Added new AOS CLA for LTP.
<p></p>
</li>
<li>Bug fixes to: LTP, CGR, SDR mutex, bpcounter, ionscript, tcpcl, stcp,
  PSM mutex, SDR, bpsink, and others.
</li>
</ul>

<h1>NOTES ON RELEASE 2.2.1</h1>

<ul>
<li>Corrected bug in LTP's data acquisition into file-system storage.  Didn't
  handle data loss and retransmission properly.
<p></p>
</li>
<li>Fixed bugs in LTP session cancellation that caused slow storage leaks.
<p></p>
</li>
<li>Upgraded the LTP configuration spreadsheet and its documentation, to
  provide better guidance when most data are sent from or acquired into
  file system storage.
<p></p>
</li>
<li>Updated the Design and Operations Guide to document new features and
  API changes.
<p></p>
</li>
<li>Various other bug fixes and tweaks.
</li>
</ul>

<h1>NOTES ON RELEASE 2.2.0</h1>

<ul>
<li>Store bundles in ZCO.
<p></p>
</li>
<li>Added feature to store bundles directly to file-system memory, allowing
  much larger bundles to be handled by the node.
<p></p>
</li>
<li>Added feature to allow all stdout output to be redirected to log files.
  Feature is enabled by #defining FSWLOGGER.
<p></p>
</li>
<li>Code scrub BP, CFDP, ICI, LTP.
<p></p>
</li>
<li>Add support for asymmetric link-delay (range) in contacts.
<p></p>
</li>
<li>Add option to configure LTP spans for "purge" behavior on contact termination.
<p></p>
</li>
<li>Fixed handling of dtn:none eids.
<p></p>
</li>
<li>Optimize contact graph routing.
<p></p>
</li>
<li>Various bug fixes and tweaks.
</li>
</ul>

<h1>NOTES ON RELEASE 2.1.0</h1>

<ul>
<li>Port to FreeBSD and RTEMS (via manual makefiles).
<p></p>
</li>
<li>Various fixes and tweaks.
<p></p>
</li>
<li>Added comprehensive automated testing suite.
<p></p>
</li>
<li>Fixed various compiler bugs
<p></p>
</li>
<li>Modified custodian EID generated from dtn:<em>hostname to dtn:</em>hostname.dtn
<p></p>
</li>
<li>Modified the loopback and ion-dtn2 configuration files for the new command syntax.
<p></p>
</li>
<li>Added BSP implementation using "stub" versions of hmac and sha1 for public release.
<p></p>
</li>
<li>Added CFDP implementation.
<p></p>
</li>
<li>Bug fixes in LTP, BRS, and some BP applications.
<p></p>
</li>
<li>Tweaks related to running on VxWorks.
<p></p>
</li>
<li>Added assertions.
<p></p>
</li>
<li>Bug fixes in the TCP convergence layer, particularly in the interest of interoperability
  with dtn2.
</li>
</ul>

<h1>NOTES ON RELEASE 2.0.0</h1>

<ul>
<li>Based on JPL revision 255:6443ed8258e1
<p></p>
</li>
<li>Converted underlying version control system to Mercurial from Subversion.
<p></p>
</li>
<li>Add ionsecadmin for managing the security policy database.
<p></p>
</li>
<li>Added better support for cross-scheme routing.
<p></p>
</li>
<li>Add support for the previous-hop-node extension.
<p></p>
</li>
<li>Update route computation to current CBHE draft standard.
<p></p>
</li>
<li>Addresses memory leak problem identified by U. of Colorado in long-duration
  tests.
<p></p>
</li>
<li>LTP heavily modified to become more flexible and powerful.
<p></p>
</li>
<li>dtnadmin and associated utilities renamed to dtn2admin.
<p></p>
</li>
<li>Configuration file syntax changes slightly in ionadmin, bpadmin, ipnadmin,
  dtn2admin; heavily changes syntax of ltpadmin.  Included ION-LTP-Configuration
  document and spreadsheet to explain new syntax and calculate values.
<p></p>
</li>
<li>Bug fixes.
<p></p>
</li>
<li>Documentation updates.
<p></p>
</li>
<li>Various testing applications in earlier releases are split from the ion release.
</li>
</ul>

<h1>NOTES ON RELEASE 1.1.0</h1>

<ul>
<li>Based on JPL revision 226.
<p></p>
</li>
<li>Experimental new tcp convergence layer compatible with the standard defined
  by draft-irtf-dtnrg-tcp-clayer-02.  This convergence layer is titled tcp,
  with other programs tcpcli tcpclo, and is suitable for connectivity with the
  DTN2 reference implementation.  Currently only unidirectional, unacknowledged
  communication is supported.  Some bugs still present.
<p></p>
</li>
<li>ION-specific tcp-based convergence layer is renamed stcp (stcpcli stcpclo)
  and still functions as expected.
<p></p>
</li>
<li>Adds user-contributed applications bping bping bpmon bpalive.
<p></p>
</li>
<li>some LTP related bugs are not yet squashed.
<p></p>
</li>
<li>Updates to various user-contrib programs; added a bpmon_query program to work
  with SNMP.
<p></p>
</li>
<li>Revise LTP to use randomly selected session numbers rather than recycling small
  session numbers - prevent data loss and corruption due to application of late-
  arriving segments to sessions that are re-using the session numbers of earlier
  sessions.
<p></p>
</li>
<li>added the bplive program.
<p></p>
</li>
<li>Updated for sbp_api.h and abp_api.c
<p></p>
</li>
<li>brought over basic working draft-tcpcl standards-compliant code with help of
  patch submitted by &lt;Andrew Jenkins (a) colorado edu&gt;
<p></p>
</li>
<li>manually applied patches from &lt;seb (a) highlab com&gt;, adding sanity-checks and more
  consistent comment-line detection to the admin programs
<p></p>
</li>
<li>Add fixes to eliminate compiler warnings, per Ohio U.  Remove all ppc-vxworks
  makefile directories, replacing them with arch-vxworks5 directories because
  the VxWorks build varies with VxWorks version number and not with the hardware
  platform that you build for.  Add "expat", which is needed by AMS and is not
  provided with VxWorks.  Fix segfault bug in dtnfw reported by U. of Colorado.
  Fix bug in support for trackingElts list.
<p></p>
</li>
<li>applied the patch from &lt;Andrew Jenkins (a) colorado edu&gt; about dtnfw's rule/plan but
<p></p>
</li>
<li>added new ION.pdf to the in-development release
<p></p>
</li>
<li>overhauled ionstart, ionscript, ionstart.awk to account for the dtnadmin need for
  a node name as well as the bpadmin/dtnadmin/ipnadmin startup order bug found by
  &lt;Andrew Jenkins (a) colorado edu&gt;
<p></p>
</li>
<li>Revise routing to match applicable backlog (based on bundle's priority; not
  necessarily total backlog) against aggregate capacity when determining route
  viability.  (Per JIRA item DINET-107)  Add implementation of extension block
  for extended class of service, which includes an additional 256 "ordinal"
  priority sub-levels within priority 2.
<p></p>
</li>
<li>Upgrade AMS implementation to Red Book 2.
<p></p>
</li>
<li>Add interface for inserting BP extensions.
</li>
</ul>

<h1>NOTES ON RELEASE 1.0_r203</h1>

<ul>
<li>Based on jpl r203.
<p></p>
</li>
<li>Adds LTP package.
<p></p>
</li>
<li>Supports contact graph routing.
<p></p>
</li>
<li>Compilation changed to autoconf and automake; compilation tested on: 
  Ubuntu 7.04, 7.10, 8.04, Gentoo, Fedora 3, Fedora 7, OSX 10.5, and Solaris 10.
<p></p>
</li>
<li>Killm updated to work on OSX 10.4, due to an ipcs incompatibility; also 
  updated to make sure all processes are killed.
<p></p>
</li>
<li>Removed multiple compiler warnings.
<p></p>
</li>
<li>Includes bundle relay programs brsscla and brsccla; brsscla acts as the 
  server, brsccla acts as the client. 
<p></p>
</li>
<li>Zco package rolled into ici.
<p></p>
</li>
<li>Ionscript added for configuration file management; ionstart and ionstop
  rewritten.
<p></p>
</li>
<li>Various bug fixes.
<p></p>
</li>
<li>2008-11-11 Added the ION Design and Operation manual v1.6.
</li>
</ul>

<h1>NOTES ON RELEASE 0.3</h1>

<ul>
<li>Based on jpl r105.
<p></p>
</li>
<li>Simplified and cleaned up SDR implementation in the ici package.
<p></p>
</li>
<li>ion package and utilities renamed to "bp" for "bundle protocol."
<p></p>
</li>
<li>Restructured congestion control to be based on rate control.
<p></p>
</li>
<li>Implements BP version 6.
<p></p>
</li>
<li>Revised the zco package.
<p></p>
</li>
<li>Added capability for dynamic routing based on network topology that changes
  with the passage of time.
<p></p>
</li>
<li>Fixed various bugs.
<p></p>
</li>
<li>All administrative and application errors are reported to ion.log
<p></p>
</li>
<li>Added ionstart and ionstop scripts.
</li>
</ul>

<h1>NOTES ON RELEASE 0.2</h1>

<ul>
<li>The ion package, which implements the DTN Bundle Protocol (BP), has been
  upgraded to conform to BP version 5, submitted to IETF in December 2006.
  The changes are almost exclusively internal to the software and protocol: 
  the format of bundles exchanged through the delay-tolerant network is altered,
  but the API for ION is mostly unchanged.  Note that this release of ION is 
  not interoperable with implementations of BP version 4.
<p></p>
</li>
<li>The Remote AMS functionality of AMS has been upgraded to conform to the 
  specification most recently posted to the public documents list of the CCSDS 
  CWE site for AMS.  The API for AMS is unchanged.
<p></p>
</li>
<li>A variety of miscellaneous bugs have been fixed.
</li>
</ul>

<h1>NOTES ON RELEASE 0.1</h1>

<ul>
<li>Initial code released for review.
</li>
</ul>

</div>
<div id="node-18" class="section-2">
  <h1 class="book-heading">Installing Ion Daemon and Tools</h1>
    <div id="node-19" class="section-3">
  <h1 class="book-heading">Software Requirements</h1>
  <p>ION requires the following software packages:</p>

<p>&nbsp;</p>

<ul><li>Modern *nix OS: Currently tested on Ubuntu Linux (8.04, 7.10,
7.04), Gentoo Linux, Fedora Core (3, 7), Apple OSX (10.5) and Solaris
10. Almost any 2.6 series Linux kernel should work.</li><li>Standard GNU core tools (<tt>tar</tt>, <tt>gzip</tt>, <tt>etc</tt>). </li><li>Standard GNU build tools (<tt>gcc</tt>, <tt>make</tt>). </li><li>The Expat XML parser (and development libraries).</li><li>The POSIX Threading library (pthreads).</li><li>Pod2man (perl tool for creating documentation files). </li><li>For now, root privileges (via <tt>sudo</tt>) for installation. </li><li>GNU autotools (<tt>autoconf</tt>, <tt>automake</tt>, <tt>libtool</tt>) make installation much easier, but are optional. </li><li><tt>Sed</tt> and <tt>awk</tt> required for some helper scripts. </li></ul>  </div>
<div id="node-20" class="section-3">
  <h1 class="book-heading">Obtaining the Ion Release</h1>
  <p>Previously,
Ion was classified under ITAR export control restrictions and required
a fairly involved process to obtain. This restriction has recently been
lifted so Ion can be much more easily distributed.</p>

<p>The Ion release you're interested in can be obtained at <a href="https://ion.ocp.ohiou.edu/drupal/project/ion">Ion's project page</a>. Either grab a release distribution or clone our Mercurial repository.</p>  </div>
<div id="node-17" class="section-3">
  <h1 class="book-heading">Compiling Ion using autotools (suggested)</h1>
  <p>Follow the standard autoconf method for compiling the project. In the base ION directory run:</p>

<p><tt>./configure</tt></p>

<p>Then compile with:</p>

<p><tt>make</tt></p>

<p>After successful compilation, you should test that your system runs
ION properly. This test currently sends data using ION over loopback. A
secondary test is run for Apple OSX users, and it may require some
modification in the amount of available shared memory (details are
given in the output):</p>

<p><tt>make test</tt></p>

<p>Finally, insall (requires root privileges):</p>

<p><tt>sudo make install</tt></p>

<p>Autotools will usually install packages such as this in the <tt>/usr/local/</tt> directory tree. This is where the example configuration files and a copy of this tutorial will end up (that is, in the <tt>share/ion</tt> subdirectory). Please move on to post-installation<a href="https://ion.ocp.ohiou.edu/tutorial/1.0/index.php?node=node7.html#postinstall"></a>.
Note that if you do not have root privileges, or would like to only run
ION locally, that adding the entire build directory to your <tt>PATH</tt> is advised- almost every ION-related program will attempt to call several others, and it will expect that they exist in the <tt>PATH</tt></p>  </div>
<div id="node-21" class="section-3">
  <h1 class="book-heading">Compiling ION Manually</h1>
  <p>In
some cases (desire to use the 'original' makefiles or a problem with
autotools) users may wish to use the NASA-JPL provided make utilities
for installation. Extract the makefiles using <tt>tar -xzf makefile.tar.gz</tt>
in the root extracted directory. This will put the makefiles in the
required directories. Manual compilation will be required for each
package (listed below). The Makefiles default to a Redhat Linux i86
architecture, but several other architectures are available. Build
order:</p>

<ul><li>ici </li><li>ltp </li><li>dgr </li><li>bp </li><li>ams </li><li>icix (optional) </li></ul>  </div>
<div id="node-22" class="section-3">
  <h1 class="book-heading">Post-Install Steps</h1>
  <p>For Linux based systems, you may need to run <tt>ldconfig</tt> with no arguments after install.</p>

<p>No other post-install steps are required if autotools were used. If autotools were not used, please read the following:</p>

<p>ION is installed into <tt>/opt</tt> by default. Therefore, you will
have to tell your shell how to access them. If you're running the bash
shell (as is the default in virtually all Linux systems), you can enter
the following lines into <tt>&nbsp;/.bashrc</tt>:</p>

<p>&nbsp;</p>

<pre>export PATH="${PATH}:/opt/bin"<br>export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/opt/lib"<br>export MANPATH="${MANPATH}:/opt/man"<br></pre>

<p>For other shells, please check your shell documentation.</p>  </div>
</div>
<div id="node-23" class="section-2">
  <h1 class="book-heading">Quick Start Guide</h1>
    <div id="node-24" class="section-3">
  <h1 class="book-heading">Programs in Ion</h1>
  <p>The following tools are available to you after ION is built:</p>

<p>&nbsp;</p>

<ul><li>Daemon and Configuration: <ul><li><tt>ionadmin</tt> is the
administration and configuration interface for the local ION node
contacts and manages shared memory resources used by ION. </li><li><tt>ltpadmin</tt> is the administration and configuration interface for LTP operations on the local ION node. </li><li><tt>bpadmin</tt> is the administrative interface for bundle protocol operations on the local ion node. </li><li><tt>ipnadmin</tt> is the administration and configuration interface for the IPN addressing system and routing on the ION node. (ipn:) </li><li><tt>dtnadmin</tt> is the administration and configuration interface for the DTN addressing system and routing on the ION node. (dtn://) </li><li><tt>killm</tt> is a script which tears down the daemon and any running ducts on a single machine (use <tt>ionstop</tt> instead). </li><li><tt>ionstart</tt> is a script which completely configures an ION node with the proper configuration file(s). </li><li><tt>ionstop</tt> is a script which completely tears down the ION node. </li><li><tt>ionscript</tt> is a script which aides in the creation and management of configuration files to be used with <tt>ionstart</tt>. </li></ul><p>&nbsp;</p></li><li>Simple Sending and Receiving: <ul><li><tt>bpsource</tt> and <tt>bpsink</tt> are for testing basic connectivity between endpoints. <tt>bpsink</tt> listens for and then displays messages sent by <tt>bpsource</tt>. </li><li><tt>bpsendfile</tt> is used to send a file between ION nodes. </li></ul><p>&nbsp;</p></li><li>Testing and Benchmarking: <ul><li><tt>bpdriver</tt> benchmarks a connection by sending bundles in two modes: request-response and streaming. </li><li><tt>bpecho</tt> issues responses to <tt>bpdriver</tt> in request-response mode. </li><li><tt>bpcounter</tt> acts as receiver for streaming mode, outputting markers on receipt of data from <tt>bpdriver</tt>. </li></ul></li></ul>

<p><span class="textbf">Logging</span></p>

<p>It is important to note that, by default, the administrative programs will all trigger the creation of a log file called <tt>ion.log</tt>
in the directory where the program is called. This means that
write-access in your current working directory is required. The log
file itself will contain the expected log information from
administrative daemons, but it will also contain error reports from
simple applications such as <tt>bpsink</tt>. This is important to note since the bundling applications may not be reporting all error information to stdout or stderr.</p>  </div>
<div id="node-25" class="section-3">
  <h1 class="book-heading">Starting the Ion Daemon</h1>
  <p>A script has been created which allows a more streamlined configuration and startup of an ION node. This script is called <tt>ionstart</tt>, and it has the following syntax. Don't run it yet; we still have to configure it!</p>

<p><tt>ionstart -I &lt;filename &gt;</tt></p>

<p>&nbsp;</p>

<ol><li><span class="textbf">filename</span>: This is the name for
configuration file which the script will attempt to use for the various
configuration commands. The script will perform a sanity check on the
file, splitting it into command sections appropriate for each of the
administration programs. </li></ol>

<p>Configuration information (such as routes, connections, etc) can be
specified one of two ways for any of the individual administration
programs:</p>

<p>&nbsp;</p>

<ol><li>(Recommended) Creating a configuration file and passing it to <tt>ionadmin</tt>, <tt>bpadmin</tt>, <tt>ipnadmin...</tt> either directly or via the <tt>ionstart</tt> helper script. </li><li>Manually typing configuration commands into the terminal for each administration program. </li></ol>

<p>You can find appropriate commands in the following sections.</p>  </div>
<div id="node-26" class="section-3">
  <h1 class="book-heading">Configuration Files Overview</h1>
  <p>There are five configuration files about which you should be aware.</p>

<p>The first, <tt>ionadmin</tt>'s configuration file, specifies contact
bandwidths and one-way transmission times. This is important in
deep-space scenarios where the bandwidth must be artificially limited
and where acknowledgments must be timed according to propagation
delays. It is also vital to the function of contact-graph routing.</p>

<p>The second, <tt>ltpadmin</tt>'s configuration file, specifies spans,
transmission speeds, and resources for the Licklider Transfer Protocol
convergence layer.</p>

<p>The third, <tt>bpadmin</tt>'s configuration file, specifies all of
the open endpoints for delivery on your local end, which convergence
layer that you intend to use. With the exception of LTP, most
convergence layers are fully configured in this file.</p>

<p>The fourth, <tt>ipnadmin</tt>'s configuration file, maps endpoints
to convergence-layer addresses. Our examples use TCP/IP and LTP (over
IP/UDP), so it maps endpoint IDs to IP addresses. This file essentially
functions as the static routing table for the IPN naming scheme.</p>

<p>The fifth, <tt>dtnadmin</tt>'s configuration file, acts as the routing table for the DTN naming scheme.</p>  </div>
<div id="node-27" class="section-3">
  <h1 class="book-heading">The Ion Configuration File</h1>
  <p>Given to <tt>ionadmin</tt>
either as a file or from the daemon command line, this file configures
contacts for the ION node. We will assume that the local element number
is 1.</p>

<p>This file specifies contact times and one-way light times between
nodes. This is useful in deep-space scenarios: for instance, Mars may
be 20 light-minutes away, or 8. Though only some transport protocols
make use of this time (currently, only LTP), it must be specified for
all links nonetheless. Times may be relative (prefixed with a + from
current time) or absolute. Absolute times, are in the format <span class="textbf">yyyy/mm/dd-hh:mm:ss</span>. By default, the contact-graph routing engine will make bundle routing decisions based on the contact information provided.</p>

<p>The configuration file lines are as follows:</p>

<p><tt>1 1 ""</tt></p>

<p>This command will initialize the ion node to be the IPN element 1.</p>

<p>&nbsp;</p>

<ul><li><tt>1</tt> refers to this being the initialization or ''first'' command. </li><li><tt>1</tt> specifies the element number of this ion node. (IPN element 1). </li><li><tt>""</tt>
specifies configuration commands for the shared memory usage of the ion
node (suitable defaults are applied if you leave this argument as an
empty string). </li></ul>

<p><tt>s</tt></p>

<p>This will start the ION node. It mostly functions to officially "start" the node in a specific instant.</p>

<p><tt>a contact +1 +3600 1 1 100000</tt></p>

<p>specifies a bandwidth for a given time duration between two connected element IDs.</p>

<p>&nbsp;</p>

<ul><li><tt>a</tt> adds this entry in the configuration table. </li><li><tt>contact</tt> specifies that this entry defines a bandwidth for a connection / duration pairing. </li><li><tt>+1</tt> is the start time for the duration (relative to when the <tt>s</tt> command is issued). </li><li><tt>+3600</tt> is the end time for the duration (relative to when the <tt>s</tt> command is issued). </li><li><tt>1</tt> is the source node IPN element number. </li><li><tt>1</tt> is the destination node IPN element number. </li><li><tt>100000</tt> is the bandwidth allocated for this time period (here, it is 100000 bytes / second). </li></ul>

<p><tt>a range +1 +3600 1 1 1</tt></p>

<p>specifies a contact distance, where each element has the following meaning:</p>

<p>&nbsp;</p>

<ul><li><tt>a</tt> adds this entry in the configuration table. </li><li><tt>range</tt> declares that what follows is a distance between two nodes. </li><li><tt>+1</tt> is the relative start window for this contact (relative to the time <tt>s</tt> was issued). </li><li><tt>+3600</tt> is the relative end window for this contact (relative to the time <tt>s</tt> was issued). </li><li><tt>1</tt> is the source node IPN element number. </li><li><tt>1</tt> is the destination node IPN element number. </li><li><tt>1</tt> is the one-way speed of light time (here, one second is the minimum). </li></ul>

<p><tt>m production 1000000</tt></p>

<p>specifies the amount of data produced by the node.</p>

<p>&nbsp;</p>

<ul><li><tt>m</tt> specifies that this is a management command. </li><li><tt>production</tt> declares that his command manages the production of this ION node. </li><li><tt>1000000</tt> specifies that 1000000 bytes/second will be produced by this node. </li></ul>

<p><tt>m consumption 1000000</tt></p>

<p>specifies the amount of data consumed by the node.</p>

<p>&nbsp;</p>

<ul><li><tt>m</tt> specifies that this is a management command. </li><li><tt>consumption</tt> declares that his command manages the data consumption of this ION node. </li><li><tt>1000000</tt> specifies that 1000000 bytes/second will be consumed by this node. </li></ul>

<p>This will make a final configuration file <tt>host1.ionrc</tt> which looks like this:</p>

<p>&nbsp;</p>

<pre>1 1 ""<br>s<br>a contact +1 +3600 1 1 100000<br>a range +1 +3600 1 1 1<br>m production 1000000<br>m consumption 1000000<br></pre>  </div>
<div id="node-28" class="section-3">
  <h1 class="book-heading">The Licklider Transfer Protocol Configuration File</h1>
  <p>Given to <tt>ltpadmin</tt>
as a file or from the command line, this file configures the LTP engine
itself. We will assume the local IPN element number is 1.</p>

<p><tt>1 32 131072</tt></p>

<p>This command will initialize the LTP engine with some memory consumption values:</p>

<p>&nbsp;</p>

<ul><li><tt>1</tt> refers to this being the initialization or ''first'' command. </li><li><tt>32</tt>
specifies the maximum number of LTP sessions. A session is assumed to
be around one second of transmission, so you should up the total
round-trip times for all contacts with neighboring nodes (see ION
configuration file Section <a href="https://ion.ocp.ohiou.edu/tutorial/1.0/index.php?node=node12.html#ion">2.4</a>). Add 20% to this value, to account for longer sessions due to a retransmission. </li><li><tt>131072</tt>
sets the block size limit of 131072 bytes. The block size should match
the amount of data that could be sent in a session- in this case, the
theoretical maximum rate of data transfer on the fastest link
available. </li></ul>

<p><tt>a span 1 1400 10000 'udplso localhost:1113'</tt></p>

<p>This command defines an LTP engine 'span.' :</p>

<p>&nbsp;</p>

<ul><li><tt>a</tt> indicates that this will add something to the engine. </li><li><tt>span</tt> indicates that an LTP span will be added. </li><li><tt>1</tt>
is the engine number of the span. In this case, it is the IPN element
number to which this span will connect. This will have to match an
outduct in Section <a href="https://ion.ocp.ohiou.edu/tutorial/1.0/index.php?node=node14.html#bp">2.6</a>. </li><li><tt>1400</tt>
is the number of bytes in a single segment. In this case, LTP runs atop
UDP/IP on ethernet, so we account for some packet overhead and use
1400. </li><li><tt>10000</tt> bytes is the nominal block size. This is
the number of bytes sent in a session- and it may contain several
bundles. This will be considered the maximum amount of data sent on
this link in a one-second session. </li><li><tt>'udplso localhost:1113'</tt>
is the command used to implement the link itself. The link is
implemented via UDP to the localhost on port 1113 (the IANA default
port for LTP over UDP). </li></ul>

<p><tt>s 'udplsi localhost:1113'</tt></p>

<p>Starts the ltp engine itself:</p>

<p>&nbsp;</p>

<ul><li><tt>s</tt> starts the ltp engine. </li><li><tt>'udplsi localhost:1113'</tt> is the link service input task. In this case, a udp listener on the local host using port 1113. </li></ul>

<p>This means that the entire configuration file <tt>host1.ltprc</tt> looks like this:</p>

<p>&nbsp;</p>

<pre>1 32 131072<br>a span 1 1400 10000 'udplso localhost:1113'<br>s 'udplsi localhost:1113'<br></pre>  </div>
<div id="node-29" class="section-3">
  <h1 class="book-heading">The Bundle Protocol Configuration File</h1>
  <p>Given to <tt>bpadmin</tt>
either as a file or from the daemon command line, this file configures
the endpoints to which this daemon will communicate. We will assume
that the local element number is 1; please change for your purposes.</p>

<p><tt>1 ipn:1.0</tt></p>

<p>This initializes the bundle protocol:</p>

<p>&nbsp;</p>

<ul><li><tt>1</tt> refers to this being the initialization or ''first'' command. </li><li><tt>ipn:1.0</tt>
defines the local custodian EID to be scheme IPN with element number 1
and service 0. In the IPN scheme, the 0 service is reserved for
custodian/administration traffic. </li></ul>

<p><tt>a scheme ipn 1 'ipnfw' 'ipnadminep'</tt></p>

<p>This adds support for a new Endpoint Identifier (EID) scheme:</p>

<p>&nbsp;</p>

<ul><li><tt>a</tt> means that this command will add something. </li><li><tt>scheme</tt> means that this command will add a scheme. </li><li><tt>ipn</tt> is the name of the scheme to be added. </li><li><tt>1</tt>
is the Compressed Bundle Header Encoding (CBHE) number associated with
the IPN scheme. Note that non-CBHE-compliant schemes (such as DTN)
should use a value of -1. </li><li><tt>'ipnfw'</tt> is the name of the IPN scheme's forwarding engine daemon. </li><li><tt>'ipnadminep'</tt> is the name of the IPN scheme's custodian daemon. </li></ul>

<p><tt>a endpoint ipn 1.0 q</tt></p>

<p>This command establishes an EID:</p>

<p>&nbsp;</p>

<ul><li><tt>a</tt> means that this command will add something. </li><li><tt>endpoint</tt> means that this command adds an endpoint. </li><li><tt>ipn</tt> is the scheme name of the endpoint. </li><li><tt>1.0</tt>
is the scheme-specific part of the endpoint. The IPN scheme requires an
endpoint ipn:element_number.0 for administrative traffic. </li><li><tt>q</tt>
means that the behavior of the engine, upon receipt of a new bundle for
this endpoint, is to queue it until an application accepts the bundle.
The alternative is to silently discard the bundle if no application is
actively listening, and this is specified by using an 'x' instead. </li></ul>

<p><tt>a endpoint ipn 1.1 q</tt> <tt>a endpoint ipn 1.2 q</tt></p>

<p>These specify two more endpoints for testing traffic.</p>

<p><tt>a protocol ltp 1400 100</tt></p>

<p>This command adds support for a convergence layer protocol:</p>

<p>&nbsp;</p>

<ul><li><tt>a</tt> means that this command will add something. </li><li><tt>protocol</tt> means that this command will add a protocol. </li><li><tt>ltp</tt> is the name of the convergence layer protocol. </li><li><tt>1400</tt> is the transmission capacity (in bytes) per unit sent (based on an IP/UDP packet on ethernet). </li><li><tt>100</tt> is the transmission overhead (in bytes) per unit sent (based on an IP/UDP packet on ethernet). </li></ul>

<p><tt>a induct ltp 1 ltpcli</tt></p>

<p>This command adds an induct, through which new bundles are received:</p>

<p>&nbsp;</p>

<ul><li><tt>a</tt> means that this command will add something. </li><li><tt>induct</tt> means that this command will add an induct. </li><li><tt>ltp</tt> is the convergence layer protocol of the induct. </li><li><tt>1</tt> is the local engine identifier of the induct. </li><li><tt>ltpcli</tt> is the name of the daemon used to implement the induct. </li></ul>

<p><tt>a outduct ltp 1 ltpclo</tt></p>

<p>This command adds an outduct, through which outgoing bundles can be sent:</p>

<p>&nbsp;</p>

<ul><li><tt>a</tt> means that this command will add something. </li><li><tt>outduct</tt> means that this command will add an outduct. </li><li><tt>ltp</tt> is the convergence layer protocol of the outduct. </li><li><tt>1</tt> is the remote engine identifier of the outduct. See Section <a href="https://ion.ocp.ohiou.edu/tutorial/1.0/index.php?node=node13.html#ltp">2.5</a> for remote engines. </li><li><tt>ltpclo</tt> is the name of the daemon used to implement the outduct. </li></ul>

<p><tt>s</tt></p>

<p>This command starts the bundle engine, inducts, outducts, and administration programs.</p>

<p>That means that the entire configuration file <tt>host1.bprc</tt> looks like this:</p>

<p>&nbsp;</p>

<pre>1 ipn:1.0<br>a scheme ipn 1 'ipnfw' 'ipnadminep'<br>a endpoint ipn 1.0 q<br>a endpoint ipn 1.1 q<br>a endpoint ipn 1.2 q<br>a protocol ltp 1400 100<br>a induct ltp 1 ltpcli<br>a outduct ltp 1 ltpclo<br>s<br></pre>  </div>
<div id="node-30" class="section-3">
  <h1 class="book-heading">IPN Routing Configuration</h1>
  <p>As
said earlier, this file is passed to the IPN routing program, and
specifies where to forward bundles destined for certain addresses
(which may or may not be locally connected). Since we can only forward
bundles to one place (our host), we only have one route.</p>

<p><tt>a service 0 admin</tt></p>

<p>This command adds a new service.</p>

<p>&nbsp;</p>

<ul><li><tt>a</tt> means that this command will add something. </li><li><tt>service</tt> means that this command will define a service. </li><li><tt>0</tt> is the service number (IPN:1.service_number); see Section <a href="https://ion.ocp.ohiou.edu/tutorial/1.0/index.php?node=node14.html#bp">2.6</a>. </li><li><tt>admin</tt> is a name assigned to the service. </li></ul>

<p><tt>a service 1 test1</tt></p>

<p><tt>a service 2 test2</tt></p>

<p>These commands define 2 more services for testing. Note that service
definitions aren't explicitly necessary unless routing rules are to be
applied.</p>

<p><tt>a plan 1 node1 x ltp/1</tt></p>

<p>This command defines an egress plan for bundles to be transmitted to the local node:</p>

<p>&nbsp;</p>

<ul><li><tt>a</tt> means this command adds something. </li><li><tt>plan</tt> means this command adds an egress plan. </li><li><tt>1</tt> is the element_number of the remote node. In this case, that is this node's number. </li><li><tt>node1</tt> is the mnemonic identifier for this plan. </li><li><tt>x</tt> means that the directive behavior is to transmit the bundle. </li><li><tt>ltp/1</tt> is the identifier of the outduct through which to transmit.</li></ul>

<p>This means that the entire configuration file <tt>host1.ipnrc</tt> looks like this:</p>

<p>&nbsp;</p>

<pre>a service 0 admin<br>a service 1 test1<br>a service 2 test2<br>a plan 1 node1 x ltp/1<br></pre>

<p>Routes are specified differently if routing through this bundling
daemon instead of delivering it to a neighbor via a local duct: see the
Section <a href="https://ion.ocp.ohiou.edu/tutorial/1.0/index.php?node=node23.html#3node">3.4</a> 3-node case for details.</p>  </div>
<div id="node-31" class="section-3">
  <h1 class="book-heading">Testing Your Connection</h1>
  <p>Assuming
no errors occur with the configuration above, we are now ready to test
loopback communications. In one terminal, we have to run the start
script (the one we said that you would have to have earlier). It's
right here, in case you forgot to write it down:</p>

<p><tt>ionstart -i host1.ionrc -l host1.ltprc -b host1.bprc -p host1.ipnrc</tt></p>

<p>This command will run the appropriate administration programs, in
order, with the appropriate configuration files. Don't worry that the
command is lengthy and unwieldly; we will show you how to make a more
clean single configuration file later.</p>

<p>Once the daemon is started, run:</p>

<p><tt>bpsink ipn:1.1</tt></p>

<p>This will begin listening on the Endpoint ID with the <tt>endpoint_number</tt> 1 on <tt>service_number</tt> 1, which is used for testing.</p>

<p>Now open another terminal and run the command:</p>

<p><tt>bpsource ipn:1.1</tt></p>

<p>This will begin sending messages you type to the Endpoint ID <tt>ipn:1.1</tt>, which is currently being listened to by <tt>bpsink</tt>. Type messages into <tt>bpsource</tt>, press enter, and see if they are reported by <tt>bpsink</tt>.</p>

<p>If so, you're ready for bigger and better things. If not, check the following:</p>

<p>&nbsp;</p>

<ul><li>Do you have write permissions for your current directory? If
not, you will not be able to start the daemon as it has to write out to
the ion.log file. </li><li>Are your config files exactly as specified, except for IP address changes? </li><li>Are you running it on one of our supported platforms? Currently, those are the only supported distributions.</li></ul>

<p>If you are still having problems, you can ask for help on the ION users' list or file an ION bug report.</p>  </div>
<div id="node-32" class="section-3">
  <h1 class="book-heading">Stopping the Daemon</h1>
  <h2><a></a></h2>

<p>As the daemon launches many ducts and helper applications, it can be
complicated to turn it all off. To help this, we provided a script. The
script similar to <tt>ionstart</tt> exists called <tt>ionstop</tt>, which tears down the ion node in one step. You can call it like so:</p>

<p><tt>ionstop</tt></p>

<p>After stopping the daemon, it can be restarted using the same
procedures as outlined above. Do remember that the ion.log file is
still present, and will just keep growing as you experiment with ION.</p>

<p><span class="textbf">IMPORTANT:</span> The user account that runs <tt>ionstart</tt> must also run <tt>ionstop</tt>.
If that account does not, no other accounts can successfully start the
daemon, as the shared memory vital to ION's functionality will already
be occupied.</p>  </div>
<div id="node-33" class="section-3">
  <h1 class="book-heading">More Advanced Usage</h1>
  <p>Detailed documentation of ION and its applications are available via man pages. It is suggested that you start with <tt>man ion</tt> , as this is an overview man page listing all available ION packages.</p>

<p>You can get more information about how ION runs and how to configure more advanced networks by examining the next section.</p>  </div>
</div>
<div id="node-34" class="section-2">
  <h1 class="book-heading">Example Networks</h1>
  <p>This section will describe some simple example networks and their configuration files. These files can be found in <tt>/usr/local/share/ion/configs</tt> after installation with autotools. The files are also in the <tt>configs</tt> directory of the extracted source tarball.</p>  <div id="node-35" class="section-3">
  <h1 class="book-heading">Ionscript for Simplified Configuration Files</h1>
  <p>The
most difficult and cumbersome method of starting an ION node is to
manually run the various administration programs in order, manually
typing configuration commands all the way. It is much more efficient
and less error-prone to place the configuration commands into a
configuration file and using that as input to the administration
program, but this is still more cumbersome as you must type in each
administration program in order. The <tt>ionstart</tt> program will
automatically execute the appropriate administration programs with
their respective configuration files in order. Unfortunately, as seen
in the previous sections,<a href="https://ion.ocp.ohiou.edu/tutorial/1.0/index.php?node=node16.html#test"></a> the command is lengthy. This is why the <tt>ionscript</tt> script was added to make things even easier.</p>

<p>The <tt>ionscript</tt> will basically concatenate the configuration
files into one large file. The format of this large configuration file
is simply to bookend configuration sections with the lines: <tt>## begin PROGRAM</tt> and <tt>## end PROGRAM</tt>, where <tt>PROGRAM</tt> is the name of the administration program for which the configuration commands should be sent (such as <tt>ionadmin, bpadmin, ipnadmin</tt>).</p>

<p>To create a single file <tt>host1.rc</tt> out of the various configuration files defined in the previous section, run this command:</p>

<p><tt>ionscript -i host1.ionrc -p host1.ipnrc -l host1.ltprc -b host1.bprc -O host1.rc</tt></p>

<p>The command can also be used to split the large <tt>host1.rc</tt>
into the individual configuration files (so long as the large file is
formatted correctly). Just run this command to revert the process:</p>

<p><tt>ionscript -i host1.ionrc -p host1.ipnrc -l host1.ltprc -b host1.bprc -I host1.rc</tt></p>

<p>This isn't very practical in this specific case (as you already have
the individual files) but if you start with a single configuration
file, this can be helpful.</p>

<p>Once you have a single configuration file, starting the ION node is a single command:</p>

<p><tt>ionstart -I host1.rc</tt></p>

<p>Note that <tt>ionstart</tt> and <tt>ionscript</tt> require <tt>sed</tt> and <tt>awk</tt>,
but those are almost universally available on Unix-based systems. The
two scripts will always sanity-check the large configuration file to
ensure that it interprets the bookend lines correctly- and it will warn
you of any errors you have made in the file. Consult the USAGE for each
script for further help, by attempting to run the script with no
arguments or the <tt>-h</tt> argument.</p>

<p>This convenient configuration file format will be used in the example networks described below.</p>  </div>
<div id="node-36" class="section-3">
  <h1 class="book-heading">Single Node Loopback</h1>
  <p>&nbsp;</p>

<p style="text-align: center;"><img src="tutorial_files/loopback.png" alt="Loop network diagram" style="vertical-align: middle;" height="185" width="242"></p>

<p>This system is formed by running the following command on Host 1:</p>

<p><tt>ionstart -I loopback.rc</tt></p>

<p>Be sure that you use the example configuration file <tt>loopback-ltp/loopback.rc</tt>:</p>

<p>&nbsp;</p>

<pre>## File created by ../../ionscript<br>## Mon Oct 27 14:56:07 EDT 2008<br>## Run the following command to start ION node:<br>##	% ionstart -I "loopback.rc"<br><br>## begin ionadmin <br># ionrc configuration file for loopback test.<br>#	This uses ltp as the primary convergence layer.<br>#	command: % ionadmin loopback.ionrc<br># 	This command should be run FIRST.<br>#<br>#	Ohio University, Oct 2008<br><br># Initialization command (command 1). <br>#	Set this node to be node 1 (as in ipn:1).<br>#	Use default sdr configuration (empty configuration file name "").<br>1 1 ""<br><br># start ion node<br>s<br><br># Add a contact.<br># 	It will start at +1 seconds from now, ending +3600 seconds from now.<br>#	It will connect node 1 to itself<br>#	It will transmit 100000 bytes/second.<br>a contact +1 +3600 1 1 100000<br><br># Add a range. This is the physical distance between nodes.<br>#	It will start at +1 seconds from now, ending +3600 seconds from now.<br>#	It will connect node 1 to itself.<br>#	Data on the link is expected to take 1 second to reach the other<br>#	end (One Way Light Time).<br>a range +1 +3600 1 1 1<br><br># set this node to consume and produce a mean of 1000000 bytes/second.<br>m production 1000000<br>m consumption 1000000<br>## end ionadmin <br><br>## begin ltpadmin <br># ltprc configuration file for the loopback test.<br>#	Command: % ltpadmin loopback.ltprc<br>#	This command should be run AFTER ionadmin and BEFORE bpadmin.<br>#<br>#	Ohio University, Oct 2008<br><br># Initialization command (command 1). <br># Establishes the LTP retransmission window. <br># (Prohibiting LTP from seizing all available storage).<br>#	A maximum of 32 sessions.  A session is assumed to be around one<br>#	second of transmission.  This value should be estimated at the sum<br>#	of maximum round-trip times (in seconds) for all "spans."<br>#	Suggest throwing 20% higher number of sessions to account for extra-<br>#	long sessions which contain an actual retransmission.<br>#	Set a block size limit of 131072 bytes.  The block size is around<br>#	the amount of data expected to be sent in a session.  Determine<br>#	this with the maximum amount of data (in bytes) transferred in one<br>#	second on your fastest available link.<br>1 32 131072<br><br># Add a span. (a connection) <br>#	Identify the span as engine number 1.<br>#	Use 1400 byte segments (assuming a standard ethernet frame<br>#	underlying this link and accounting for ip/udp/eth header overhead).<br>#	Use a nominal block size of 10000 bytes.  This is the amount of data<br>#	(which can span several bundles) sent in a session.  You should<br>#	consider this to be the maximum number of bytes sent in one second<br>#	on the link. (you can also use the block size limit in the<br>#	initialization command).<br>#	Use the command 'udplso localhost:1113' to implement the link<br>#	itself.  In this case, we use udp to connect to localhost (this is<br>#	loopback) using port 1113 (defined by IANA as the default UDP port<br>#	for Licklider Transmission Protocol).  The single quote is<br>#	important, don't use double quotes.<br>a span 1 1400 10000 'udplso localhost:1113'<br><br># Start command.<br>#	This command actually runs the link service output commands<br>#	(defined above, in the "a span" commands).<br>#	Also starts the link service INPUT task 'udplsi localhost:1113' to<br>#	listen locally on UDP port 1113 for incoming LTP traffic.<br>s 'udplsi localhost:1113'<br>## end ltpadmin <br><br>## begin bpadmin <br># bprc configuration file for the loopback test.<br>#	Command: % bpadmin loopback.bprc<br>#	This command should be run AFTER ionadmin and ltpadmin and <br>#	BEFORE ipnadmin or dtnadmin.<br>#<br>#	Ohio University, Oct 2008<br><br># Initialization command (command 1).<br>#	Use ipn:1.0 as the custodian endpoint of this node.<br>#	That is, scheme IPN with element_number 1 and service number 0<br>#	(ipn requires custodian service is zero).<br>#	Note that this EID must be understood by the node itself, so be sure<br>#	to add the scheme below.<br>1 ipn:1.0<br><br># Add an EID scheme.<br>#	The scheme's name is ipn.<br>#	The scheme's number is 1.  Note that this number is defined for<br>#	Compressed Bundle Header Encoding (CBHE) schemes ONLY.  All other<br>#	schemes (dtn for example) should use number -1.<br>#	This scheme's forwarding engine is handled by the program 'ipnfw.'<br>#	This scheme's administration program (acting as the custodian<br>#	daemon) is 'ipnadminep.'<br>a scheme ipn 1 'ipnfw' 'ipnadminep'<br><br># Add endpoints.<br>#	Establish endpoints ipn:1.0 ipn:1.1 and ipn:1.2 on the local node.<br>#	ipn:1.0 is expected for custodian traffic.  The rest are usually<br>#	used for specific applications (such as bpsink).<br>#	The behavior for receiving a bundle when there is no application<br>#	currently accepting bundles, is to queue them 'q', as opposed to<br>#	immediately and silently discarding them (use 'x' instead of 'q' to<br>#	discard).<br>a endpoint ipn 1.0 q<br>a endpoint ipn 1.1 q<br>a endpoint ipn 1.2 q<br><br># Add a protocol. <br>#	Add the protocol named ltp.<br>#	Estimate transmission capacity assuming 1400 bytes of each frame (in<br>#	this case, udp on ethernet) for payload, and 100 bytes for overhead.<br>a protocol ltp 1400 100<br><br># Add an induct. (listen)<br>#	Add an induct to accept bundles using the ltp protocol.<br>#	The duct's name is 1 (this is for future changing/deletion of the<br>#	induct).<br>#	The induct itself is implemented by the 'ltpcli' command.<br>a induct ltp 1 ltpcli<br><br># Add an outduct. (send to yourself)<br>#	Add an outduct to send bundles using the ltp protocol.<br>#	The duct's name is 1 (this is for future changing/deletion of the<br>#	outduct).<br>#	The outduct itself is implemented by the 'ltpclo' command.<br>a outduct ltp 1 ltpclo<br><br># Start bundle protocol engine, also running all of the induct, outduct,<br># and administration programs defined above<br>s<br>## end bpadmin <br><br>## begin ipnadmin <br># ipnrc configuration file for the loopback test.<br>#	Essentially, this is the IPN scheme's routing table.<br>#	Command: % ipnadmin loopback.ipnrc<br>#	This command should be run AFTER bpadmin (likely to be run last).<br>#<br>#	Ohio University, Oct 2008<br><br># Add services<br>#	Add service 0 (i.e. ipn:1.0) called 'admin.'<br>#	Add service 1 (ipn:1.1) called 'test1.'<br>#	Add service 2 (ipn:1.2) called 'test2.'<br>#	See your bprc file for endpoint IDs you should use.<br>a service 0 admin<br>a service 1 test1<br>a service 2 test2<br><br># Add an egress plan.<br>#	Bundles to be transmitted to element number 1 (that is, yourself).<br>#	This element is named 'node1.'<br>#	The plan is to queue for transmission (x) on protocol 'ltp' using<br>#	the outduct identified as '1.'<br>#	See your bprc file or bpadmin for outducts/protocols you can use.<br>a plan 1 node1 x ltp/1<br>## end ipnadmin<br></pre>  </div>
<div id="node-37" class="section-3">
  <h1 class="book-heading">Two-Node Ring</h1>
  <p>&nbsp;</p>

<p style="text-align: center;"><img src="tutorial_files/2node.png" alt="Two-Node Diagram" height="165" width="430"></p>

<p>In this section, we assume that host1 has an IP address of 10.1.1.1
and host2 has an IP address of 10.1.1.2. Please modify this for your
uses.</p>

<p>Note that this example network uses a different convergence layer: TCP.</p>

<p>This network is created by running the following command on Host 1:</p>

<p><tt>ionstart host1.rc</tt></p>

<p>Host 2 must run this command:</p>

<p><tt>ionstart host2.rc</tt></p>

<p>The configuration files are found in the <tt>2node-tcp</tt> directory:</p>

<p><tt>host1.rc</tt>:</p>

<p>&nbsp;</p>

<pre>## File created by ../../../../branches/release-1.0_r203/ionscript<br>## Wed Oct 29 17:28:46 EDT 2008<br>## Run the following command to start ION node:<br>##	% ionstart -I "host1.rc"<br><br>## begin ionadmin <br># ionrc configuration file for host1 in a 2node tcp test.<br>#	This uses tcp as the primary convergence layer.<br>#	command: % ionadmin host1.ionrc<br># 	This command should be run FIRST.<br>#<br>#	Ohio University, Oct 2008<br><br># Initialization command (command 1). <br>#	Set this node to be node 1 (as in ipn:1).<br>#	Use default sdr configuration (empty configuration file name "").<br>1 1 ""<br><br># start ion node<br>s<br><br># Add a contact.<br># 	It will start at +1 seconds from now, ending +3600 seconds from now.<br>#	It will connect node 1 to itself<br>#	It will transmit 100000 bytes/second.<br>a contact +1 +3600 1 1 100000<br><br># Add more contacts.<br>#	They will connect 1 to 2, 2 to 1, and 2 to itself<br>#	Note that contacts are unidirectional, so order matters.<br>a contact +1 +3600 1 2 100000<br>a contact +1 +3600 2 1 100000<br>a contact +1 +3600 2 2 100000<br><br># Add a range. This is the physical distance between nodes.<br>#	It will start at +1 seconds from now, ending +3600 seconds from now.<br>#	It will connect node 1 to itself.<br>#	Data on the link is expected to take 1 second to reach the other<br>#	end (One Way Light Time).<br>a range +1 +3600 1 1 1<br><br># Add more ranges.<br>#	We will assume every range is one second.<br>#	Note that ranges cover both directions, so you only need define<br>#	one range for any combination of nodes.<br>a range +1 +3600 2 2 1<br>a range +1 +3600 2 1 1<br><br># set this node to consume and produce a mean of 1000000 bytes/second.<br>m production 1000000<br>m consumption 1000000<br>## end ionadmin <br><br>## begin bpadmin <br># bprc configuration file for host1 in a 2node test.<br>#	Command: % bpadmin host1.bprc<br>#	This command should be run AFTER ionadmin and BEFORE ipnadmin<br>#	or dtnadmin.<br>#<br>#	Ohio University, Oct 2008<br><br># Initialization command (command 1).<br>#	Use ipn:1.0 as the custodian endpoint of this node.<br>#	That is, scheme IPN with element_number 1 and service number 0<br>#	(ipn requires custodian service to be zero).<br>#	Note that this EID must be understood by the node itself, so be sure<br>#	to add the scheme below.<br>1 ipn:1.0<br><br># Add an EID scheme.<br>#	The scheme's name is ipn.<br>#	The scheme's number is 1.  Note that this number is defined for<br>#	Compressed Bundle Header Encoding (CBHE) schemes ONLY.  All other<br>#	schemes (dtn for example) should use number -1.<br>#	This scheme's forwarding engine is handled by the program 'ipnfw.'<br>#	This scheme's administration program (acting as the custodian<br>#	daemon) is 'ipnadminep.'<br>a scheme ipn 1 'ipnfw' 'ipnadminep'<br><br># Add endpoints.<br>#	Establish endpoints ipn:1.0 ipn:1.1 and ipn:1.2 on the local node.<br>#	ipn:1.0 is expected for custodian traffic.  The rest are usually<br>#	used for specific applications (such as bpsink).<br>#	The behavior for receiving a bundle when there is no application<br>#	currently accepting bundles, is to dump them 'x', as opposed to<br>#	queueing them (use 'q' instead of 'x' to queue).<br>a endpoint ipn 1.0 x<br>a endpoint ipn 1.1 x<br>a endpoint ipn 1.2 x<br><br># Add a protocol. <br>#	Add the protocol named tcp.<br>#	Estimate transmission capacity assuming 1400 bytes of each frame (in<br>#	this case, tcp on ethernet) for payload, and 100 bytes for overhead.<br>a protocol tcp 1400 100<br><br># Add an induct. (listen)<br>#	Add an induct to accept bundles using the tcp protocol.<br>#	The induct will listen at this host's IP address (private testbed).<br>#	The induct will listen on port 4556, the IANA assigned default DTN<br>#	TCP convergence layer port.<br>#	The induct itself is implemented by the 'tcpcli' command.<br>a induct tcp 10.1.1.1:4556 tcpcli<br><br># Add an outduct. (send to yourself)<br>#	Add an outduct to send bundles using the tcp protocol.<br>#	The outduct will connect to the IP address 10.1.1.1 using the<br>#	IANA assigned default DTN TCP port of 4556.<br>#	The outduct itself is implemented by the 'tcpclo' command.<br>a outduct tcp 10.1.1.1:4556 tcpclo<br><br># Add an outduct. (send to host2)<br>#	Add an outduct to send bundles using the tcp protocol.<br>#	The outduct will connect to the IP address 10.1.1.2 using the<br>#	IANA assigned default DTN TCP port of 4556.<br>#	The outduct itself is implemented by the 'tcpclo' command.<br>a outduct tcp 10.1.1.2:4556 tcpclo<br><br># Start bundle protocol engine, also running all of the induct, outduct,<br># and administration programs defined above.<br>s<br>## end bpadmin <br><br>## begin ipnadmin <br># ipnrc configuration file for host1 in the 2node tcp network.<br>#	Essentially, this is the IPN scheme's routing table.<br>#	Command: % ipnadmin host1.ipnrc<br>#	This command should be run AFTER bpadmin (likely to be run last).<br>#<br>#	Ohio University, Oct 2008<br><br># Add services<br>#	Add service 0 (i.e. ipn:1.0) called 'admin.'<br>#	Add service 1 (ipn:1.1) called 'test1.'<br>#	Add service 2 (ipn:1.2) called 'test2.'<br>#	See your bprc file for endpoint IDs you should use.<br>a service 0 admin<br>a service 1 test1<br>a service 2 test2<br><br># Add an egress plan. (to yourself)<br>#	Bundles to be transmitted to element number 1 (that is, yourself).<br>#	This element is named 'host1.'<br>#	The plan is to queue for transmission (x) on protocol 'tcp' using<br>#	the outduct identified as '10.1.1.1:4556'<br>#	See your bprc file or bpadmin for outducts/protocols you can use.<br>a plan 1 host1 x tcp/10.1.1.1:4556<br><br># Add an egress plan. (to the second host)<br>#	Bundles to be transmitted to element number 2 (the other node).<br>#	This element is named 'host2.'<br>#	The plan is to queue for transmission (x) on protocol 'tcp' using<br>#	the outduct identified as '10.1.1.2:4556'<br>#	See your bprc file or bpadmin for outducts/protocols you can use.<br>a plan 2 host2 x tcp/10.1.1.2:4556<br>## end ipnadmin<br></pre>

<p><tt>host2.rc</tt>:</p>

<p>&nbsp;</p>

<pre>## File created by ../../../../branches/release-1.0_r203/ionscript<br>## Wed Oct 29 17:28:46 EDT 2008<br>## Run the following command to start ION node:<br>##	% ionstart -I "host2.rc"<br><br>## begin ionadmin <br># ionrc configuration file for host2 in a 2node tcp test.<br>#	This uses tcp as the primary convergence layer.<br>#	command: % ionadmin host2.ionrc<br># 	This command should be run FIRST.<br>#<br>#	Ohio University, Oct 2008<br><br># Initialization command (command 1). <br>#	Set this node to be node 2 (as in ipn:2).<br>#	Use default sdr configuration (empty configuration file name "").<br>1 2 ""<br><br># start ion node<br>s<br><br># Add a contact.<br># 	It will start at +1 seconds from now, ending +3600 seconds from now.<br>#	It will connect node 1 to itself<br>#	It will transmit 100000 bytes/second.<br>a contact +1 +3600 1 1 100000<br><br># Add more contacts.<br>#	They will connect 1 to 2, 2 to 1, and 2 to itself<br>#	Note that contacts are unidirectional, so order matters.<br>a contact +1 +3600 1 2 100000<br>a contact +1 +3600 2 1 100000<br>a contact +1 +3600 2 2 100000<br><br># Add a range. This is the physical distance between nodes.<br>#	It will start at +1 seconds from now, ending +3600 seconds from now.<br>#	It will connect node 1 to itself.<br>#	Data on the link is expected to take 1 second to reach the other<br>#	end (One Way Light Time).<br>a range +1 +3600 1 1 1<br><br># Add more ranges.<br>#	We will assume every range is one second.<br>#	Note that ranges cover both directions, so you only need define<br>#	one range for any combination of nodes.<br>a range +1 +3600 2 2 1<br>a range +1 +3600 2 1 1<br><br># set this node to consume and produce a mean of 1000000 bytes/second.<br>m production 1000000<br>m consumption 1000000<br>## end ionadmin <br><br>## begin bpadmin <br># bprc configuration file for host2 in a 2node test.<br>#	Command: % bpadmin host2.bprc<br>#	This command should be run AFTER ionadmin and BEFORE ipnadmin<br>#	or dtnadmin.<br>#<br>#	Ohio University, Oct 2008<br><br># Initialization command (command 1).<br>#	Use ipn:2.0 as the custodian endpoint of this node.<br>#	That is, scheme IPN with element_number 2 and service number 0<br>#	(ipn requires custodian service to be zero).<br>#	Note that this EID must be understood by the node itself, so be sure<br>#	to add the scheme below.<br>1 ipn:2.0<br><br># Add an EID scheme.<br>#	The scheme's name is ipn.<br>#	The scheme's number is 1.  Note that this number is defined for<br>#	Compressed Bundle Header Encoding (CBHE) schemes ONLY.  All other<br>#	schemes (dtn for example) should use number -1.<br>#	This scheme's forwarding engine is handled by the program 'ipnfw.'<br>#	This scheme's administration program (acting as the custodian<br>#	daemon) is 'ipnadminep.'<br>a scheme ipn 1 'ipnfw' 'ipnadminep'<br><br># Add endpoints.<br>#	Establish endpoints ipn:2.0 ipn:2.1 and ipn:2.2 on the local node.<br>#	ipn:2.0 is expected for custodian traffic.  The rest are usually<br>#	used for specific applications (such as bpsink).<br>#	The behavior for receiving a bundle when there is no application<br>#	currently accepting bundles, is to dump them 'x', as opposed to<br>#	queueing them (use 'q' instead of 'x' to queue).<br>a endpoint ipn 2.0 x<br>a endpoint ipn 2.1 x<br>a endpoint ipn 2.2 x<br><br># Add a protocol. <br>#	Add the protocol named tcp.<br>#	Estimate transmission capacity assuming 1400 bytes of each frame (in<br>#	this case, tcp on ethernet) for payload, and 100 bytes for overhead.<br>a protocol tcp 1400 100<br><br># Add an induct. (listen)<br>#	Add an induct to accept bundles using the tcp protocol.<br>#	The induct will listen at this host's IP address (private testbed).<br>#	The induct will listen on port 4556, the IANA assigned default DTN<br>#	TCP convergence layer port.<br>#	The induct itself is implemented by the 'tcpcli' command.<br>a induct tcp 10.1.1.2:4556 tcpcli<br><br># Add an outduct. (send to yourself)<br>#	Add an outduct to send bundles using the tcp protocol.<br>#	The outduct will connect to the IP address 10.1.1.2 using the<br>#	IANA assigned default DTN TCP port of 4556.<br>#	The outduct itself is implemented by the 'tcpclo' command.<br>a outduct tcp 10.1.1.2:4556 tcpclo<br><br># Add an outduct. (send to host1)<br>#	Add an outduct to send bundles using the tcp protocol.<br>#	The outduct will connect to the IP address 10.1.1.1 using the<br>#	IANA assigned default DTN TCP port of 4556.<br>#	The outduct itself is implemented by the 'tcpclo' command.<br>a outduct tcp 10.1.1.1:4556 tcpclo<br><br># Start bundle protocol engine, also running all of the induct, outduct,<br># and administration programs defined above.<br>s<br>## end bpadmin <br><br>## begin ipnadmin <br># ipnrc configuration file for host1 in the 2node tcp network.<br>#	Essentially, this is the IPN scheme's routing table.<br>#	Command: % ipnadmin host2.ipnrc<br>#	This command should be run AFTER bpadmin (likely to be run last).<br>#<br>#	Ohio University, Oct 2008<br><br># Add services<br>#	Add service 0 (i.e. ipn:2.0) called 'admin.'<br>#	Add service 1 (ipn:2.1) called 'test1.'<br>#	Add service 2 (ipn:2.2) called 'test2.'<br>#	See your bprc file for endpoint IDs you should use.<br>a service 0 admin<br>a service 1 test1<br>a service 2 test2<br><br># Add an egress plan. (to yourself)<br>#	Bundles to be transmitted to element number 2 (that is, yourself).<br>#	This element is named 'host2.'<br>#	The plan is to queue for transmission (x) on protocol 'tcp' using<br>#	the outduct identified as '10.1.1.2:4556'<br>#	See your bprc file or bpadmin for outducts/protocols you can use.<br>a plan 2 host2 x tcp/10.1.1.2:4556<br><br># Add an egress plan. (to the other host)<br>#	Bundles to be transmitted to element number 1 (the other node).<br>#	This element is named 'host1.'<br>#	The plan is to queue for transmission (x) on protocol 'tcp' using<br>#	the outduct identified as '10.1.1.1:4556'<br>#	See your bprc file or bpadmin for outducts/protocols you can use.<br>a plan 1 host1 x tcp/10.1.1.1:4556<br>## end ipnadmin<br></pre>  </div>
<div id="node-38" class="section-3">
  <h1 class="book-heading">Three-Node Network</h1>
  <p>&nbsp;</p>

<p style="text-align: center;"><img src="tutorial_files/3node.png" alt="Three-Node Diagram" height="132" width="569"></p>

<p>In this section, we assume that host1 has an IP address of 10.1.1.1,
host2 has an IP address of 10.1.1.2, and host3 has an IP address of
10.1.1.3. Please modify this for your uses.</p>

<p>You will notice that this network uses host2 as a router in between
host1 and host3. At this point, routing is handled by creating a group
from the remote node and using the middle node as the gateway. Notice
how host1 will take traffic for host3 and transmit it on the same
outduct to host2, the next hop. Host3 will transmit traffic destined
for host1 on the outduct for host2, also the next hop.</p>

<p>Also note that this network uses both LTP and TCP convergence layers.</p>

<p>This network is created by running the following command on Host 1:</p>

<p><tt>ionstart -I host1.rc</tt></p>

<p>This command is run on Host 2:</p>

<p><tt>ionstart -I host2.rc</tt></p>

<p>This command is run on Host 3:</p>

<p><tt>ionstart -I host3.rc</tt></p>

<p>The config files can be found in the <tt>3node-tcp-ltp</tt> directory.</p>

<p><tt>host1.rc</tt>:</p>

<p>&nbsp;</p>

<pre>## File created by ../../ionscript<br>## Wed Oct 29 17:33:43 EDT 2008<br>## Run the following command to start ION node:<br>##	% ionstart -I "host1.rc"<br><br>## begin ionadmin <br># ionrc configuration file for host1 in a 3node tcp/ltp test.<br>#	This uses ltp from 1 to 2 and ltp from 2 to 3.<br>#	command: % ionadmin host1.ionrc<br># 	This command should be run FIRST.<br>#<br>#	Ohio University, Oct 2008<br><br># Initialization command (command 1). <br>#	Set this node to be node 1 (as in ipn:1).<br>#	Use default sdr configuration (empty configuration file name "").<br>1 1 ""<br><br># start ion node<br>s<br><br># Add a contact.<br># 	It will start at +1 seconds from now, ending +3600 seconds from now.<br>#	It will connect node 1 to itself.<br>#	It will transmit 100000 bytes/second.<br>a contact +1 +3600 1 1 100000<br><br># Add more contacts.<br>#	The network goes 1--2--3<br>#	Note that contacts are unidirectional, so order matters.<br>a contact +1 +3600 1 2 100000<br>a contact +1 +3600 2 1 100000<br>a contact +1 +3600 2 2 100000<br>a contact +1 +3600 2 3 100000<br>a contact +1 +3600 3 2 100000<br>a contact +1 +3600 3 3 100000<br><br># Add a range. This is the physical distance between nodes.<br>#	It will start at +1 seconds from now, ending +3600 seconds from now.<br>#	It will connect node 1 to itself.<br>#	Data on the link is expected to take 1 second to reach the other<br>#	end (One Way Light Time).<br>a range +1 +3600 1 1 1<br><br># Add more ranges.<br>#	We will assume every range is one second.<br>#	Note that ranges cover both directions, so you only need define<br>#	one range for any combination of nodes.<br>a range +1 +3600 1 2 1<br>a range +1 +3600 1 3 2<br>a range +1 +3600 2 2 1<br>a range +1 +3600 2 3 1<br>a range +1 +3600 3 3 1<br><br># set this node to consume and produce a mean of 1000000 bytes/second.<br>m production 1000000<br>m consumption 1000000<br>## end ionadmin <br><br>## begin ltpadmin <br># ltprc configuration file for host1 in a 3node ltp/tcp test.<br>#	Command: % ltpadmin host1.ltprc<br>#	This command should be run AFTER ionadmin and BEFORE bpadmin.<br>#<br>#	Ohio University, Oct 2008<br><br># Initialization command (command 1). <br># Establishes the LTP retransmission window. <br># (Prohibiting LTP from seizing all available storage).<br>#	A maximum of 32 sessions.  A session is assumed to be around one<br>#	second of transmission.  This value should be estimated at the sum<br>#	of maximum round-trip times (in seconds) for all "spans."<br>#	Suggest throwing 20% higher number of sessions to account for extra-<br>#	long sessions which contain an actual retransmission.<br>#	Set a block size limit of 131072 bytes.  The block size is around<br>#	the amount of data expected to be sent in a session.  Determine<br>#	this with the maximum amount of data (in bytes) transferred in one<br>#	second on your fastest available link.<br>1 32 131072<br><br># Add a span. (a connection) <br>#	Identify the span as engine number 1.<br>#	Use 1400 byte segments (assuming a standard ethernet frame<br>#	underlying this link and accounting for ip/udp/eth header overhead).<br>#	Use a nominal block size of 10000 bytes.  This is the amount of data<br>#	(which can span several bundles) sent in a session.  You should<br>#	consider this to be the maximum number of bytes sent in one second<br>#	on the link. (you can also use the block size limit in the<br>#	initialization command).<br>#	Use the command 'udplso 10.1.1.1:1113' to implement the link<br>#	itself.  In this case, we use udp to connect to the local machine<br>#	(loopback) using port 1113 (defined by IANA as the default UDP port<br>#	for Licklider Transmission Protocol).  The single quote is<br>#	important, don't use double quotes.<br>a span 1 1400 10000 'udplso 10.1.1.1:1113'<br><br># Add another span. (to host2) <br>#	Identify the span as engine number 2.<br>#	Use the command 'udplso 10.1.1.2:1113' to implement the link<br>#	itself.  In this case, we use udp to connect to host2 using the<br>#	default port.<br>a span 2 1400 10000 'udplso 10.1.1.2:1113'<br><br># Start command.<br>#	This command actually runs the link service output commands<br>#	(defined above, in the "a span" commands).<br>#	Also starts the link service INPUT task 'udplsi 10.1.1.1:1113' to<br>#	listen locally on UDP port 1113 for incoming LTP traffic.<br>s 'udplsi 10.1.1.1:1113'<br>## end ltpadmin <br><br>## begin bpadmin <br># bprc configuration file for host1 in a 3node ltp/tcp test.<br>#	Command: % bpadmin host1.bprc<br>#	This command should be run AFTER ionadmin and ltpadmin and <br>#	BEFORE ipnadmin or dtnadmin.<br>#<br>#	Ohio University, Oct 2008<br><br># Initialization command (command 1).<br>#	Use ipn:1.0 as the custodian endpoint of this node.<br>#	That is, scheme IPN with element_number 1 and service number 0<br>#	(ipn requires custodian service is zero).<br>#	Note that this EID must be understood by the node itself, so be sure<br>#	to add the scheme below.<br>1 ipn:1.0<br><br># Add an EID scheme.<br>#	The scheme's name is ipn.<br>#	The scheme's number is 1.  Note that this number is defined for<br>#	Compressed Bundle Header Encoding (CBHE) schemes ONLY.  All other<br>#	schemes (dtn for example) should use number -1.<br>#	This scheme's forwarding engine is handled by the program 'ipnfw.'<br>#	This scheme's administration program (acting as the custodian<br>#	daemon) is 'ipnadminep.'<br>a scheme ipn 1 'ipnfw' 'ipnadminep'<br><br># Add endpoints.<br>#	Establish endpoints ipn:1.0 ipn:1.1 and ipn:1.2 on the local node.<br>#	ipn:1.0 is expected for custodian traffic.  The rest are usually<br>#	used for specific applications (such as bpsink).<br>#	The behavior for receiving a bundle when there is no application<br>#	currently accepting bundles, is to queue them 'q', as opposed to<br>#	immediately and silently discarding them (use 'x' instead of 'q' to<br>#	discard).<br>a endpoint ipn 1.0 x<br>a endpoint ipn 1.1 x<br>a endpoint ipn 1.2 x<br><br># Add a protocol. <br>#	Add the protocol named ltp.<br>#	Estimate transmission capacity assuming 1400 bytes of each frame (in<br>#	this case, udp on ethernet) for payload, and 100 bytes for overhead.<br>a protocol ltp 1400 100<br><br># Add an induct. (listen)<br>#	Add an induct to accept bundles using the ltp protocol.<br>#	The duct's name is 1 (this is for future changing/deletion of the<br>#	induct). <br>#	The induct itself is implemented by the 'ltpcli' command.<br>a induct ltp 1 ltpcli<br><br># Add an outduct. (send to yourself)<br>#	Add an outduct to send bundles using the ltp protocol.<br>#	The duct's name is 1 (this is for future changing/deletion of the<br>#	outduct). The name should correspond to a span (in your ltprc).<br>#	The outduct itself is implemented by the 'ltpclo' command.<br>a outduct ltp 1 ltpclo<br># NOTE:	what happens if 1 does not match the id of an ltp span?<br><br># Add an outduct. (send to host2)<br>#	Add an outduct to send bundles using the ltp protocol.<br>#	The duct's name is 2 (this is for future changing/deletion of the<br>#	outduct). The name should correpsond to a span (in your ltprc).<br>#	The outduct itself is implemented by the 'ltpclo' command.<br>a outduct ltp 2 ltpclo<br><br># Start bundle protocol engine, also running all of the induct, outduct,<br># and administration programs defined above<br>s<br>## end bpadmin <br><br>## begin ipnadmin <br># ipnrc configuration file for host1 in a 3node ltp/tcp test. <br>#	Essentially, this is the IPN scheme's routing table.<br>#	Command: % ipnadmin host1.ipnrc<br>#	This command should be run AFTER bpadmin (likely to be run last).<br>#<br>#	Ohio University, Oct 2008<br><br># Add services<br>#	Add service 0 (i.e. ipn:1.0) called 'admin.'<br>#	Add service 1 (ipn:1.1) called 'test1.'<br>#	Add service 2 (ipn:1.2) called 'test2.'<br>#	See your bprc file for endpoint IDs you should use.<br>a service 0 admin<br>a service 1 test1<br>a service 2 test2<br><br># Add an egress plan.<br>#	Bundles to be transmitted to element number 1 (that is, yourself).<br>#	This element is named 'host1.'<br>#	The plan is to queue for transmission (x) on protocol 'ltp' using<br>#	the outduct identified as '1.'<br>#	See your bprc file or bpadmin for outducts/protocols you can use.<br>a plan 1 host1 x ltp/1<br><br># Add other egress plans.<br>#	Bundles for elemetn 2 can be transmitted directly to host2 using<br>#	ltp outduct identified as '2.' See bprc file for available outducts<br>#	and/or protocols.<br>a plan 2 host2 x ltp/2<br><br># Add a group static route<br>#	host 3 is not a neighbor to host1, but it is a neighbor to host2.<br>#	send bundles for 3 via 2.<br>a group 3 3 2<br>## end ipnadmin<br></pre>

<p><tt>host2.rc</tt>:</p>

<p>&nbsp;</p>

<pre>## File created by ../../ionscript<br>## Wed Oct 29 17:33:43 EDT 2008<br>## Run the following command to start ION node:<br>##	% ionstart -I "host2.rc"<br><br>## begin ionadmin <br># ionrc configuration file for host2 in a 3node tcp/ltp test.<br>#	This uses ltp from 1 to 2 and ltp from 2 to 3.<br>#	command: % ionadmin host2.ionrc<br># 	This command should be run FIRST.<br>#<br>#	Ohio University, Oct 2008<br><br># Initialization command (command 1). <br>#	Set this node to be node 2 (as in ipn:2).<br>#	Use default sdr configuration (empty configuration file name "").<br>1 2 ""<br><br># start ion node<br>s<br><br># Add a contact.<br># 	It will start at +1 seconds from now, ending +3600 seconds from now.<br>#	It will connect node 1 to itself.<br>#	It will transmit 100000 bytes/second.<br>a contact +1 +3600 1 1 100000<br><br># Add more contacts.<br>#	The network goes 1--2--3<br>#	Note that contacts are unidirectional, so order matters.<br>a contact +1 +3600 1 2 100000<br>a contact +1 +3600 2 1 100000<br>a contact +1 +3600 2 2 100000<br>a contact +1 +3600 2 3 100000<br>a contact +1 +3600 3 2 100000<br>a contact +1 +3600 3 3 100000<br><br># Add a range. This is the physical distance between nodes.<br>#	It will start at +1 seconds from now, ending +3600 seconds from now.<br>#	It will connect node 1 to itself.<br>#	Data on the link is expected to take 1 second to reach the other<br>#	end (One Way Light Time).<br>a range +1 +3600 1 1 1<br><br># Add more ranges.<br>#	We will assume every range is one second.<br>#	Note that ranges cover both directions, so you only need define<br>#	one range for any combination of nodes.<br>a range +1 +3600 1 2 1<br>a range +1 +3600 1 3 2<br>a range +1 +3600 2 2 1<br>a range +1 +3600 2 3 1<br>a range +1 +3600 3 3 1<br><br># set this node to consume and produce a mean of 1000000 bytes/second.<br>m production 1000000<br>m consumption 1000000<br>## end ionadmin <br><br>## begin ltpadmin <br># ltprc configuration file for host2 in a 3node ltp/tcp test.<br>#	Command: % ltpadmin host2.ltprc<br>#	This command should be run AFTER ionadmin and BEFORE bpadmin.<br>#<br>#	Ohio University, Oct 2008<br><br># Initialization command (command 1). <br># Establishes the LTP retransmission window. <br># (Prohibiting LTP from seizing all available storage).<br>#	A maximum of 32 sessions.  A session is assumed to be around one<br>#	second of transmission.  This value should be estimated at the sum<br>#	of maximum round-trip times (in seconds) for all "spans."<br>#	Suggest throwing 20% higher number of sessions to account for extra-<br>#	long sessions which contain an actual retransmission.<br>#	Set a block size limit of 131072 bytes.  The block size is around<br>#	the amount of data expected to be sent in a session.  Determine<br>#	this with the maximum amount of data (in bytes) transferred in one<br>#	second on your fastest available link.<br>1 32 131072<br><br># Add a span. (a connection) <br>#	Identify the span as engine number 1.<br>#	Use 1400 byte segments (assuming a standard ethernet frame<br>#	underlying this link and accounting for ip/udp/eth header overhead).<br>#	Use a nominal block size of 10000 bytes.  This is the amount of data<br>#	(which can span several bundles) sent in a session.  You should<br>#	consider this to be the maximum number of bytes sent in one second<br>#	on the link. (you can also use the block size limit in the<br>#	initialization command).<br>#	Use the command 'udplso 10.1.1.1:1113' to implement the link<br>#	itself.  In this case, we use udp to connect to the local machine<br>#	(loopback) using port 1113 (defined by IANA as the default UDP port<br>#	for Licklider Transmission Protocol).  The single quote is<br>#	important, don't use double quotes.<br>a span 1 1400 10000 'udplso 10.1.1.1:1113'<br><br># Add another span. (to yourself) <br>#	Identify the span as engine number 2.<br>#	Use the command 'udplso 10.1.1.2:1113' to implement the link<br>#	itself.  In this case, we use udp to connect to host2 using the<br>#	default port.<br>a span 2 1400 10000 'udplso 10.1.1.2:1113'<br><br># Start command.<br>#	This command actually runs the link service output commands<br>#	(defined above, in the "a span" commands).<br>#	Also starts the link service INPUT task 'udplsi 10.1.1.2:1113' to<br>#	listen locally on UDP port 1113 for incoming LTP traffic.<br>s 'udplsi 10.1.1.2:1113'<br>## end ltpadmin <br><br>## begin bpadmin <br># bprc configuration file for host2 in a 3node ltp/tcp test.<br>#	Command: % bpadmin host2.bprc<br>#	This command should be run AFTER ionadmin and ltpadmin and <br>#	BEFORE ipnadmin or dtnadmin.<br>#<br>#	Ohio University, Oct 2008<br><br># Initialization command (command 1).<br>#	Use ipn:2.0 as the custodian endpoint of this node.<br>#	That is, scheme IPN with element_number 2 and service number 0<br>#	(ipn requires custodian service is zero).<br>#	Note that this EID must be understood by the node itself, so be sure<br>#	to add the scheme below.<br>1 ipn:2.0<br><br># Add an EID scheme.<br>#	The scheme's name is ipn.<br>#	The scheme's number is 1.  Note that this number is defined for<br>#	Compressed Bundle Header Encoding (CBHE) schemes ONLY.  All other<br>#	schemes (dtn for example) should use number -1.<br>#	This scheme's forwarding engine is handled by the program 'ipnfw.'<br>#	This scheme's administration program (acting as the custodian<br>#	daemon) is 'ipnadminep.'<br>a scheme ipn 1 'ipnfw' 'ipnadminep'<br><br># Add endpoints.<br>#	Establish endpoints ipn:2.0 ipn:2.1 and ipn:2.2 on the local node.<br>#	ipn:2.0 is expected for custodian traffic.  The rest are usually<br>#	used for specific applications (such as bpsink).<br>#	The behavior for receiving a bundle when there is no application<br>#	currently accepting bundles, is to queue them 'q', as opposed to<br>#	immediately and silently discarding them (use 'x' instead of 'q' to<br>#	discard).<br>a endpoint ipn 2.0 x<br>a endpoint ipn 2.1 x<br>a endpoint ipn 2.2 x<br><br># Add a protocol. <br>#	Add the protocol named ltp.<br>#	Estimate transmission capacity assuming 1400 bytes of each frame (in<br>#	this case, udp on ethernet) for payload, and 100 bytes for overhead.<br>a protocol ltp 1400 100<br><br># Add a protocol. <br>#	Add the protocol named tcp.<br>#	Estimate transmission capacity assuming 1400 bytes of each frame (in<br>#	this case, tcp on ethernet) for payload, and 100 bytes for overhead.<br>a protocol tcp 1400 100<br><br># Add an induct. (listen)<br>#	Add an induct to accept bundles using the ltp protocol.<br>#	The duct's name is 2 (this is for future changing/deletion of the<br>#	induct). <br>#	The induct itself is implemented by the 'ltpcli' command.<br>a induct ltp 2 ltpcli<br><br># Add an induct. (listen)<br>#	Add an induct to accept bundles using the tcp protocol.<br>#	The induct will listen at this host's IP address (private testbed).<br>#	The induct will listen on port 4556, the IANA assigned default DTN<br>#	TCP convergence layer port.<br>#	The induct itself is implemented by the 'tcpcli' command.<br>a induct tcp 10.1.1.2:4556 tcpcli<br><br># Add an outduct. (send to yourself)<br>#	Add an outduct to send bundles using the tcp protocol.<br>#	The outduct will connect to the IP address 10.1.1.2 using the<br>#	IANA assigned default DTN TCP port of 4556.<br>#	The outduct itself is implemented by the 'tcpclo' command.<br>a outduct tcp 10.1.1.2:4556 tcpclo<br><br># Add an outduct. (send to host3)<br>#	Add an outduct to send bundles using the tcp protocol.<br>#	The outduct will connect to the IP address 10.1.1.3 using the<br>#	IANA assigned default DTN TCP port of 4556.<br>#	The outduct itself is implemented by the 'tcpclo' command.<br>a outduct tcp 10.1.1.3:4556 tcpclo<br><br># Add an outduct. (send to host1)<br>#	Add an outduct to send bundles using the ltp protocol.<br>#	The duct's name is 1 (this is for future changing/deletion of the<br>#	outduct). The name should correpsond to a span (in your ltprc).<br>#	The outduct itself is implemented by the 'ltpclo' command.<br>a outduct ltp 1 ltpclo<br><br># Start bundle protocol engine, also running all of the induct, outduct,<br># and administration programs defined above<br>s<br>## end bpadmin <br><br>## begin ipnadmin <br># ipnrc configuration file for host2 in a 3node ltp/tcp test. <br>#	Essentially, this is the IPN scheme's routing table.<br>#	Command: % ipnadmin host2.ipnrc<br>#	This command should be run AFTER bpadmin (likely to be run last).<br>#<br>#	Ohio University, Oct 2008<br><br># Add services<br>#	Add service 0 (i.e. ipn:2.0) called 'admin.'<br>#	Add service 1 (ipn:2.1) called 'test1.'<br>#	Add service 2 (ipn:2.2) called 'test2.'<br>#	See your bprc file for endpoint IDs you should use.<br>a service 0 admin<br>a service 1 test1<br>a service 2 test2<br><br># Add an egress plan. (to yourself)<br>#	Bundles to be transmitted to element number 2 (that is, yourself).<br>#	This element is named 'host2.'<br>#	The plan is to queue for transmission (x) on protocol 'tcp' using<br>#	the outduct identified as '10.1.1.2:4556'<br>#	See your bprc file or bpadmin for outducts/protocols you can use.<br>a plan 2 host2 x tcp/10.1.1.2:4556<br><br># Add an egress plan. (to host3)<br>#	Bundles to be transmitted to element number 3 (the other node).<br>#	This element is named 'host3.'<br>#	The plan is to queue for transmission (x) on protocol 'tcp' using<br>#	the outduct identified as '10.1.1.3:4556'<br>#	See your bprc file or bpadmin for outducts/protocols you can use.<br>a plan 3 host3 x tcp/10.1.1.3:4556<br><br># Add an egress plan. (to host1)<br>#	Bundles to be transmitted to element number 1.<br>#	This element is named 'host1.'<br>#	The plan is to queue for transmission (x) on protocol 'ltp' using<br>#	the outduct identified as '1.'<br>#	See your bprc file or bpadmin for outducts/protocols you can use.<br>a plan 1 host1 x ltp/1<br>## end ipnadmin<br></pre>

<p><tt>host3.rc</tt>:</p>

<p>&nbsp;</p>

<pre>## File created by ../../ionscript<br>## Wed Oct 29 17:33:43 EDT 2008<br>## Run the following command to start ION node:<br>##	% ionstart -I "host3.rc"<br><br>## begin ionadmin <br># ionrc configuration file for host3 in a 3node tcp/ltp test.<br>#	This uses ltp from 1 to 2 and ltp from 2 to 3.<br>#	command: % ionadmin host3.ionrc<br># 	This command should be run FIRST.<br>#<br>#	Ohio University, Oct 2008<br><br># Initialization command (command 1). <br>#	Set this node to be node 3 (as in ipn:3).<br>#	Use default sdr configuration (empty configuration file name "").<br>1 3 ""<br><br># start ion node<br>s<br><br># Add a contact.<br># 	It will start at +1 seconds from now, ending +3600 seconds from now.<br>#	It will connect node 1 to itself.<br>#	It will transmit 100000 bytes/second.<br>a contact +1 +3600 1 1 100000<br><br># Add more contacts.<br>#	The network goes 1--2--3<br>#	Note that contacts are unidirectional, so order matters.<br>a contact +1 +3600 1 2 100000<br>a contact +1 +3600 2 1 100000<br>a contact +1 +3600 2 2 100000<br>a contact +1 +3600 2 3 100000<br>a contact +1 +3600 3 2 100000<br>a contact +1 +3600 3 3 100000<br><br># Add a range. This is the physical distance between nodes.<br>#	It will start at +1 seconds from now, ending +3600 seconds from now.<br>#	It will connect node 1 to itself.<br>#	Data on the link is expected to take 1 second to reach the other<br>#	end (One Way Light Time).<br>a range +1 +3600 1 1 1<br><br># Add more ranges.<br>#	We will assume every range is one second.<br>#	Note that ranges cover both directions, so you only need define<br>#	one range for any combination of nodes.<br>a range +1 +3600 1 2 1<br>a range +1 +3600 1 3 2<br>a range +1 +3600 2 2 1<br>a range +1 +3600 2 3 1<br>a range +1 +3600 3 3 1<br><br># set this node to consume and produce a mean of 1000000 bytes/second.<br>m production 1000000<br>m consumption 1000000<br>## end ionadmin <br><br>## begin bpadmin <br># bprc configuration file for host3 in a 3node ltp/tcp test.<br>#	Command: % bpadmin host3.bprc<br>#	This command should be run AFTER ionadmin and <br>#	BEFORE ipnadmin or dtnadmin.<br>#<br>#	Ohio University, Oct 2008<br><br># Initialization command (command 1).<br>#	Use ipn:3.0 as the custodian endpoint of this node.<br>#	That is, scheme IPN with element_number 3 and service number 0<br>#	(ipn requires custodian service is zero).<br>#	Note that this EID must be understood by the node itself, so be sure<br>#	to add the scheme below.<br>1 ipn:3.0<br><br># Add an EID scheme.<br>#	The scheme's name is ipn.<br>#	The scheme's number is 1.  Note that this number is defined for<br>#	Compressed Bundle Header Encoding (CBHE) schemes ONLY.  All other<br>#	schemes (dtn for example) should use number -1.<br>#	This scheme's forwarding engine is handled by the program 'ipnfw.'<br>#	This scheme's administration program (acting as the custodian<br>#	daemon) is 'ipnadminep.'<br>a scheme ipn 1 'ipnfw' 'ipnadminep'<br><br># Add endpoints.<br>#	Establish endpoints ipn:3.0 ipn:3.1 and ipn:3.2 on the local node.<br>#	ipn:3.0 is expected for custodian traffic.  The rest are usually<br>#	used for specific applications (such as bpsink).<br>#	The behavior for receiving a bundle when there is no application<br>#	currently accepting bundles, is to queue them 'q', as opposed to<br>#	immediately and silently discarding them (use 'x' instead of 'q' to<br>#	discard).<br>a endpoint ipn 3.0 x<br>a endpoint ipn 3.1 x<br>a endpoint ipn 3.2 x<br><br># Add a protocol. <br>#	Add the protocol named tcp.<br>#	Estimate transmission capacity assuming 1400 bytes of each frame (in<br>#	this case, tcp on ethernet) for payload, and 100 bytes for overhead.<br>a protocol tcp 1400 100<br><br># Add an induct. (listen)<br>#	Add an induct to accept bundles using the tcp protocol.<br>#	The induct will listen at this host's IP address (private testbed).<br>#	The induct will listen on port 4556, the IANA assigned default DTN<br>#	TCP convergence layer port.<br>#	The induct itself is implemented by the 'tcpcli' command.<br>a induct tcp 10.1.1.3:4556 tcpcli<br><br># Add an outduct. (send to yourself)<br>#	Add an outduct to send bundles using the tcp protocol.<br>#	The outduct will connect to the IP address 10.1.1.3 using the<br>#	IANA assigned default DTN TCP port of 4556.<br>#	The outduct itself is implemented by the 'tcpclo' command.<br>a outduct tcp 10.1.1.3:4556 tcpclo<br><br># Add an outduct. (send to host2)<br>#	Add an outduct to send bundles using the tcp protocol.<br>#	The outduct will connect to the IP address 10.1.1.2 using the<br>#	IANA assigned default DTN TCP port of 4556.<br>#	The outduct itself is implemented by the 'tcpclo' command.<br>a outduct tcp 10.1.1.2:4556 tcpclo<br><br># Start bundle protocol engine, also running all of the induct, outduct,<br># and administration programs defined above<br>s<br>## end bpadmin <br><br>## begin ipnadmin <br># ipnrc configuration file for host3 in a 3node ltp/tcp test. <br>#	Essentially, this is the IPN scheme's routing table.<br>#	Command: % ipnadmin host3.ipnrc<br>#	This command should be run AFTER bpadmin (likely to be run last).<br>#<br>#	Ohio University, Oct 2008<br><br># Add services<br>#	Add service 0 (i.e. ipn:3.0) called 'admin.'<br>#	Add service 1 (ipn:3.1) called 'test1.'<br>#	Add service 2 (ipn:3.2) called 'test2.'<br>#	See your bprc file for endpoint IDs you should use.<br>a service 0 admin<br>a service 1 test1<br>a service 2 test2<br><br># Add an egress plan. (to yourself)<br>#	Bundles to be transmitted to element number 3 (that is, yourself).<br>#	This element is named 'host3.'<br>#	The plan is to queue for transmission (x) on protocol 'tcp' using<br>#	the outduct identified as '10.1.1.3:4556'<br>#	See your bprc file or bpadmin for outducts/protocols you can use.<br>a plan 3 host3 x tcp/10.1.1.3:4556<br><br># Add an egress plan. (to host2)<br>#	Bundles to be transmitted to element number 2 (the other node).<br>#	This element is named 'host2.'<br>#	The plan is to queue for transmission (x) on protocol 'tcp' using<br>#	the outduct identified as '10.1.1.2:4556'<br>#	See your bprc file or bpadmin for outducts/protocols you can use.<br>a plan 2 host2 x tcp/10.1.1.2:4556<br><br># Add a group static route.<br>#	Host1 is not a neigbor to host3, but is is a neighbor to host 2;<br>#	send bundles for 1 via 2.<br>a group 1 1 2<br>## end ipnadmin<br></pre>  </div>
</div>
<div id="node-39" class="section-2">
  <h1 class="book-heading">Support</h1>
    <div id="node-41" class="section-3">
  <h1 class="book-heading">Bug Reports</h1>
  <p>For bug support, we ask for the following:</p>

<p>&nbsp;</p>

<ul><li>The version of the ION distribution used, such as 0.3. </li><li>The operating system/s used on the host/s. </li><li>The version of gcc used to compile code (use <tt>gcc -v</tt>). </li><li>All configuration files. </li><li>The ion.log file from the host/s.</li></ul>

<p>If you'd like to submit a bug report, please create an <a href="https://ion.ocp.ohiou.edu/drupal/node/add/project-issue/ion">Issue</a> on our bug tracking system</p>  </div>
<div id="node-40" class="section-3">
  <h1 class="book-heading">Mailng Lists</h1>
  <p>The following mailing lists exist for ION support:</p>

<p>&nbsp;</p><p> </p>

<ul><li><tt>ion-announce</tt> for announcements regarding ION releases, security vulnerabilities, etc. </li> <li><tt>ion-bugs</tt> for users to file bug reports. See the "Bug Reports" section for more information on that. </li> <li><tt>ion-users</tt> for anyone interested in ION discussions. </li> </ul>

<p>You can sign up for these lists here:</p>

<p>&nbsp;</p><p> </p>

<ul><li><tt>ion-announce</tt>: <a href="http://korgano.eecs.ohiou.edu/mailman/listinfo/ion-announce">http://korgano.eecs.ohiou.edu/mailman/listinfo/ion-announce</a> </li> <li><tt>ion-bugs</tt>: <a href="http://korgano.eecs.ohiou.edu/mailman/listinfo/ion-bugs">http://korgano.eecs.ohiou.edu/mailman/listinfo/ion-bugs </a></li> <li><tt>ion-users</tt>: <a href="http://korgano.eecs.ohiou.edu/mailman/listinfo/ion-users">http://korgano.eecs.ohiou.edu/mailman/listinfo/ion-users </a></li></ul>  </div>
</div>
<div id="node-14" class="section-2">
  <h1 class="book-heading">Frequently Asked Questions</h1>
    </div>
<div id="node-42" class="section-2">
  <h1 class="book-heading">About This Document</h1>
  <p>This documentation was ported from the original HTML by Ilya Kogan on 2008-08-12.</p>

<p>The original document was created<strong>LaTeX</strong>and translated into HTML using the <a href="http://www.latex2html.org/"><strong>LaTeX</strong>2<tt>HTML</tt></a> translator Version 2002-2-1 (1.71)</p>

<p>Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds. <br>Copyright © 1997, 1998, 1999, <a href="http://www.maths.mq.edu.au/%7Eross/">Ross Moore</a>, Mathematics Department, Macquarie University, Sydney.</p>

<p>The command line arguments were: <br><strong>latex2html</strong> <tt>-local_icons tutorial.tex</tt></p>

<p>The translation was initiated by dave on 2008-11-01</p>  </div>
</div>
    
  </body></html>