File: rfc1582.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1627 lines) | stat: -rw-r--r-- 63,271 bytes parent folder | download | duplicates (8)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627






Network Working Group                                           G. Meyer
Request for Comments: 1582                                Spider Systems
Category: Standards Track                                  February 1994


              Extensions to RIP to Support Demand Circuits

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   Running routing protocols on connection oriented Public Data
   Networks, for example X.25 packet switched networks or ISDN, can be
   expensive if the standard form of periodic broadcasting of routing
   information is adhered to.  The high cost arises because a connection
   has to all practical intents and purposes be kept open to every
   destination to which routing information is to be sent, whether or
   not it is being used to carry user data.

   Routing information may also fail to be propagated if the number of
   destinations to which the routing information is to be sent exceeds
   the number of channels available to the router on the Wide Area
   Network (WAN).

   This memo defines a generalized modification which can be applied to
   Bellman-Ford (or distance vector) algorithm information broadcasting
   protocols, for example IP RIP, Netware RIP or Netware SAP, which
   overcomes the limitations of the traditional methods described above.

   The routing protocols support a purely triggered update mechanism on
   demand circuits on WANs.  The protocols run UNMODIFIED on LANs or
   fixed point-to-point links.

   Routing information is sent on the WAN when the routing database is
   modified by new routing information received from another interface.
   When this happens a (triggered) update is sent to a list of
   destinations on other WAN interfaces.  Because routing protocols are
   datagram based they are not guaranteed to be received by the peer
   router on the WAN.  An acknowledgement and retransmission mechanism
   is provided to ensure that routing updates are received.





Meyer                                                           [Page 1]

RFC 1582                       Demand RIP                  February 1994


   The WAN circuit manager advises the routing applications on the
   reachability and non-reachability of destinations on the WAN.

Acknowledgements

   I would like to thank colleagues at Spider, in particular Richard
   Edmonstone, Tom Daniel and Alam Turland, Yakov Rekhter (IBM), Martha
   Steenstrup (BBN), and members of the RIP-2 working group of the IETF
   for stimulating discussions and comments which helped to clarify this
   memo.

Conventions

   The following language conventions are used in the items of
   specification in this document:

      o  MUST -- the item is an absolute requirement of the specification.
         MUST is only used where it is actually required for interoperation,
         not to try to impose a particular method on implementors
         where not required for interoperability.

      o  SHOULD -- the item should be followed for all but exceptional cir-
         cumstances.

      o  MAY or optional -- the item is truly optional and may be followed
         or ignored according to the needs of the implementor.

   The words "should" and "may" are also used, in lower case, in their
   more ordinary senses.

Table of Contents

      1. Introduction ...........................................  3
      2. Running a routing Protocol on the WAN ..................  4
          2.1. Overview .........................................  4
          2.2. Presumption of Reachability ......................  6
          2.3. WAN Router list ..................................  7
          2.4. Triggered Updates and Unreliable Delivery ........  8
          2.5. Guaranteeing delivery of Routing Updates .........  8
          2.6. The Routing Database .............................  9
          2.7. New Packet Types ................................. 10
          2.8. Fragmentation .................................... 12
          2.9. Preventing Queue Overload ........................ 13
      3. IP Routing Information Protocol Version 1 .............. 13
      4. IP Routing Information Protocol Version 2 .............. 16
      5. Netware Routing Information Protocol ................... 17
      6. Netware Service Advertising Protocol ................... 20
      7. Timers ................................................. 24



Meyer                                                           [Page 2]

RFC 1582                       Demand RIP                  February 1994


          7.1. Database Timer ................................... 24
          7.2. Retransmission Timer ............................. 25
          7.3. Reassembly Timer ................................. 26
      8. Implementation Considerations ...........................27
      9. Security Considerations ................................ 27
     10. References ............................................. 28
     11. Author's Address ....................................... 29

1. Introduction

   Routers are used on connection oriented networks, such as X.25 packet
   switched networks and ISDN networks, to allow potential connectivity
   to a large number of remote destinations.  Circuits on the Wide Area
   Network (WAN) are established on demand and are relinquished when the
   traffic subsides.  Depending on the application, the connection
   between any two sites for user data might actually be short and
   relatively infrequent.

   Practical experience of routing shows that periodic 'broadcasting' of
   routing updates on the WAN is unsatisfactory on several counts:

   o  Running a routing protocol like RIP is expensive if the standard
      form of transmitting routing information to every next hop router
      every 30 seconds is adhered to.  The more routers there are
      wishing to exchange information the worse the problem.  If there
      are N routers on the WAN, N * (N - 1) routing updates are sent over
      N * (N - 1)/2 connections every broadcast period.

      The expense arises because a circuit has to be kept open to each
      destination to which routing information is to be sent.  Routing
      updates are sufficiently frequent that little benefit is obtainable
      on most networks by attempting to set up a call purely for
      the duration of the routing update. (There are often minimum call
      charges, or there is a charge to set up a call irrespective of
      what data is sent.)

      The option of reducing the 'broadcast' frequency, while reducing
      the cost, would make the system less responsive.

   o  The number of networks to be connected (N) on the WAN can easily
      exceed the number of simultaneous calls (M) which the interface
      can support.  If this happens the routing 'broadcast' will only
      reach M next hop routers, and (N - M) next hop routers will not
      receive the routing update.

      A basic rate ISDN interface can support 2 simultaneous calls, and
      even the number of logical channels most users subscribe to on an
      X.25 network is not large.  There is no fundamental reason why



Meyer                                                           [Page 3]

RFC 1582                       Demand RIP                  February 1994


      routing protocols should restrict the user to routing between so
      few sites.

   o  Since there is no broadcast facility on the WAN, 'broadcasting' of
      routing information actually consists of sending the updates
      separately to all known locations.  This means that N routing
      updates are queued for transmission on the WAN link (in addition
      to any data which might be queued).

      Routers take a pragmatic view on queuing datagrams for the WAN.
      If the queue length gets too long, so that datagrams at the end of
      the queue would take too long be transmitted in a reasonable time
      (say 1 to 2 seconds) the router may start discarding them.  On an
      X.25 network, with slow line speeds (perhaps 9600 baud), it may
      not take too many routing updates to fulfill this condition if the
      link is also actively being used to carry user data.

   This memo addresses all the above problems.

   The approach taken is to modify the routing protocols so as to send
   information on the WAN only when there has been an update to the
   routing database OR a change in the reachability of a next hop router
   is indicated by the task which manages connections on the WAN.

   Because datagrams are not guaranteed to get through on all WAN media,
   an acknowledgement and retransmission system is required to provide
   reliability.

   This memo describes the modifications required for Bellman-Ford (or
   distance vector) algorithm information broadcasting protocols, such
   as IP RIP [1,2] or Netware RIP and SAP [3] on the WAN.  The protocols
   run unmodified on Local Area Networks (LANs) or fixed point-to-point
   links, and so interoperate transparently with implementations
   adhering to the original specifications.

2. Running Routing Protocols on the WAN

2.1 Overview

   Multiprotocol routers are used on connection oriented Wide Area
   Networks (WANs), such as X.25 packet switched networks and ISDN
   networks, to interconnect LANs.  By using the multiplexing properties
   of the underlying WAN technology, several LANs can be interconnected
   simultaneously through a single physical interface on the router.

   A circuit manager provides an interface between the connectionless
   network layers (IP, IPX, CLNP etc) and the connection oriented WAN
   (X.25 or ISDN).  Figure 1 shows a schematic representative stack



Meyer                                                           [Page 4]

RFC 1582                       Demand RIP                  February 1994


   showing the relationship between routing protocols, the network
   layers, the circuit manager and the connection oriented WAN.

             --------------           ---------  ---------
             |    RIP     |           |  RIP  |  |  SAP  |
             --------------           ---------  ---------
                   |                      |          |
             --------------               |          |
             |    UDP     |               |          |
             --------------               |          |
                   |                      |          |
             --------------             ----------------
             |    IP      |             |     IPX      |
             --------------             ----------------
                   |                           |
             -------------------------------------------
             |             Circuit Manager             |
             -------------------------------------------
                              ||||||||||
                              ||||||||||
                      ---------------------------
                      |   Connection Oriented   |
                      |        WAN stack        |
                      ---------------------------

     A WAN circuit manager will support a variety of network layer
     protocols, on its upper interface.  On its lower interface, it
     may support one or more subnetworks.  A subnetwork may support a
     number of Virtual Circuits.


            Figure 1.   Representative Multiprotocol Router stack

   The router has a translation table which relates the network layer
   address of the next hop router to the physical address used to
   establish a Virtual Circuit (VC) to it.  Datagrams may be
   encapsulated in a header to distinguish the network layer protocol
   [5].

   The circuit manager takes datagrams from the connectionless network
   layer protocols and (if one is not currently available) opens a VC to
   the next hop router.  A VC can carry all traffic between two end-
   point routers for a given network layer protocol (or with appropriate
   encapsulation all network layer protocols).  An idle timer is used to
   close the VC when the datagrams stop arriving at the circuit manager.

   Running routing protocols on the WAN has traditionally consisted of
   making small modifications to the methods used on LANs.  Where



Meyer                                                           [Page 5]

RFC 1582                       Demand RIP                  February 1994


   routing information would be broadcast periodically on a LAN
   interface, it is converted to a series of periodic updates sent to a
   list of addresses on the WAN.

   This memo targets two areas:

   o  Eliminating the overkill inherent in periodic transmission of
      routing updates.

   o  Overcoming the bandwidth limitations on the WAN: the number of
      simultaneous VCs to next hop routers and restricted data
      throughput which the WAN link can support.

   The first of these is overcome by transmitting routing updates
   (called routing responses) only when required:

   o  Firstly, when a specific request for a routing update has been
      received.

   o  Secondly, when the routing database is modified by new
      information from another interface.

      Update information received in this way is not normally
      propagated on other interfaces immediately, but is delayed for a
      few seconds to allow information from several updates to be
      grouped.

   o  Thirdly, when the circuit manager indicates that a destination
      has changed from an unreachable (circuit down) to a reachable
      (circuit up) state.

   Because of the inherent unreliability of a datagram based system,
   both routing requests and routing responses require acknowledgement,
   and retransmission in the event of NOT receiving an acknowledgement.

   To overcome the bandwidth limitations the routing application can
   perform a form of self-imposed flow control, to spread routing
   updates out over a period of time.

2.2 Presumption of Reachability

   If a routing update is received from a next hop router on the WAN,
   entries in the update are thereafter always considered to be
   reachable, unless proven otherwise:

   o  If in the normal course of routing datagrams, the circuit manager
      fails to establish a connection to the next hop router, it
      notifies the routing application that the next hop router is not



Meyer                                                           [Page 6]

RFC 1582                       Demand RIP                  February 1994


      reachable through an internal circuit down message.

      The routing application then goes through a process of timing out
      database entries to make them unreachable in the routing sense.

   o  If the circuit manager is subsequently able to establish a
      connec tion to the next hop router, it will notify the routing
      applica tion that the next hop router is reachable through an
      internal circuit up message.

      The routing application will then exchange messages with the next
      hop router so as to re-prime their respective routing databases
      with up-to-date information.

   Handling of circuit up and circuit down messages requires that the
   circuit manager takes responsibility for establishing (or
   reestablishing) the connection in the event of a next hop router
   becoming unreachable.  A description of the processes the circuit
   manager adopts to perform this task is outside the scope of this
   memo.

2.3 WAN Router list

   The routing task MAY be provided with a list of routers to send
   routing updates to on the WAN.  It will comprise of the logical
   addresses of next hop routers for which the router has a logical to
   physical address mapping.  Entries in the list SHOULD be categorized
   (on a per-peer basis) as follows:

   o  Running the standard routing protocol, namely transmitting
      updates periodically with the packet formats used in LAN
      broadcasts.

      This option is supported to allow interoperability with existing
      routing implementations, and might also be appropriate if some
      of the destinations are using Permanent Virtual Circuits (PVCs)
      rather than SVCs.

   o  Running the triggered update routing protocol proposed in this
      memo.

   Omitting an address from both of these categories is equivalent to
   not running the routing protocols.

   If routing packets arrive from a destination not supporting the
   appropriate variant they MUST be discarded.





Meyer                                                           [Page 7]

RFC 1582                       Demand RIP                  February 1994


2.4 Triggered Updates and Unreliable Delivery

   If triggered update information is sent to next hop routers on the
   WAN only once it can fail to arrive for one of the following reasons:

   o  A free VC resource might not be available, because of a
      restricted number of X.25 logical channels or ISDN B-channels.

   o  The transmit queue might be full - requiring the datagram to be
      discarded.

   o  The VC might be pre-empted (in favour of establishing a VC to
      another next hop router) while the datagram is in a queue,
      resulting in the queue being flushed and the datagram
      discarded.

   o  In cases where the method of transport is not guaranteed, for
      example with PPP where there is no acknowledgement and
      retransmission of HDLC frames, a corrupted frame will result in
      the loss of the datagram.

2.5 Guaranteeing delivery of Routing Updates

   To guarantee delivery of routing updates on the WAN an
   acknowledgement and retransmission scheme MUST be used:

   o  Send a routing update to a next hop router on the WAN.

   o  The other router responds with an acknowledgement packet.

      The original router receives the acknowledgement.

   o  Otherwise the original router retransmits the update until an
      acknowledgement is received.

      Retransmission timer values are covered in section 7.

      In cases where the routing database is modified before an
      acknowledgement is received a new routing update with an
      updated sequence number is sent out.  If an acknowledgement for
      the old routing update is received it is ignored.

   o  A router only updates its routing database when it receives a
      complete update, which may consist of several fragments.  Each
      fragment is individually acknowledged.

   The above mechanism caters for cases where the datagram is lost
   because of a frame error or is discarded because of an over-full



Meyer                                                           [Page 8]

RFC 1582                       Demand RIP                  February 1994


   queue.  The routing update and acknowledgement will eventually both
   get through.

   In cases where the circuit manager cannot establish a connection, a
   mechanism is provided to allow the circuit manager to inform the
   routing task of the failure to make a connection so that it can
   suppress retransmissions until a circuit becomes available.

2.6 The Routing Database

   A requirement of using triggered updates for propagating routing
   information is that NO routing information ever gets LOST or
   DISCARDED.

   The routing database MUST adopt one of the following strategies:

   o  It must keep ALL alternative routing information it learns from
      any routing updates from the LAN and the WAN, so that if the
      best route disappears an alternative route (if available) can
      replace it as the new best route.

   o  If the amount of memory this consumes is problematic the routing
      application must keep SOME alternative routing information - say
      a best route and two alternatives.

      If the router ever has to discard routing information about a
      route it should note the fact.  If the routes that have been
      kept disappear because they have become unreachable, the router
      MUST issue a request on all interfaces to try and obtain
      discarded alternatives.

      It is recommended that the request is issued BEFORE all routes
      to a destination have been lost.

   Entries in the routing database can either be permanent or temporary.
   Entries learned from broadcasts on LANs are temporary. They will
   expire if not periodically refreshed by further broadcasts.

   Entries learned from a triggered response on the WAN are 'permanent'.
   They MUST not time out in the normal course of events.  The entries
   state MUST be changed to 'temporary' by the following events:

   o  The arrival of a routing update containing the entry set to
      unreachable.

      The normal hold down timer MUST be started, after which the
      entry disappears from the routing database.




Meyer                                                           [Page 9]

RFC 1582                       Demand RIP                  February 1994


   o  The arrival of a routing update with the entry absent.

      If the hold down timer is not already running, the entry MUST be
      set to unreachable and the hold down timer started.

   o  A message sent from the circuit manager, to indicate that it
      failed to make a connection in normal running.

      The routing table MUST be scanned for all routes via that next
      hop router.  Aging of these routing entries MUST commence.  If
      the aging timer expires the entry MUST be set to unreachable and
      the hold down timer started.  If the hold down timer expires the
      entry disappears from the routing database.

   o  If the interface goes down, the circuit manager should indicate
      that all circuits on that interface have gone down.

   Database timer values are covered in section 7.

2.7 New Packet Types

   To support triggered updates, three new packet types MUST be
   supported:

   TRIGGERED REQUEST

             A request to the responding system to send all
             appropriate elements in its routing database.

             A triggered request is retransmitted at periodic
             intervals until a triggered response is received.

             Routing requests are transmitted in the following
             circumstances:

             o  Firstly when the router is powered on.

             o  Secondly when the circuit manager indicates a
                destination has been in an unreachable (circuit down)
                state for an extended period and changes to a
                reachable (circuit up) state.

             o  Thirdly in the event of all routing update fragments
                failing to arrive within a set period.

             o  It may also send triggered requests at other times to
                compensate for discarding non-optimal routing
                information.



Meyer                                                          [Page 10]

RFC 1582                       Demand RIP                  February 1994


   TRIGGERED RESPONSE

             A message containing all appropriate elements of the
             routing database.  An appropriate element is an entry
             NOT learned from the interface to which the routing
             information is being sent out.  This is known as "split
             horizon".

             Stability is improved by adding "poisoned reverse" on
             routes learned from a destination.  This consists of also
             including some routes learned from a destination in
             routing updates sent back to that destination, but
             setting the routes as unreachable.  A route is only
             poisoned if it is the best route (rather than an inferior
             alternative route) in the database.

             A triggered response message may be sent in response to a
             triggered request, or it may be an update message issued
             because of a change in the routing database.

             A triggered response message MUST be sent in response to
             a triggered request message even if there are no routes
             to propagate.  This would be the case for a host which
             had a WAN interface only, but which wished to run the
             triggered update protocol.

             A triggered response is retransmitted at periodic
             intervals until a triggered acknowledgement is received.

   TRIGGERED ACKNOWLEDGEMENT

             A message sent in response to every triggered response
             packet received.

   Triggered response and triggered acknowledgement packets MUST contain
   additional fields for a sequence number, fragment number and number
   of fragments.

   If a triggered request or response is not acknowledged after 10
   retransmissions, routes to the destination should be marked as
   unreachable for the duration of a hold down timer before being
   deleted.

   The destination should then be polled at a lower frequency using
   triggered request packets.  When a triggered response is received,
   the router should prime the next hop router my sending its routing
   database through triggered response packets.




Meyer                                                          [Page 11]

RFC 1582                       Demand RIP                  February 1994


   Strictly speaking polling should occur indefinitely to guarantee
   database integrity.  However the administrator MAY wish the router to
   cease polling after a few attempts believing that the lack of
   response is due to a mis-configuration of the next hop router.  The
   destination should be marked as NOT supporting the mechanism and no
   further routing messages should be sent to that destination.

   Before marking the destination as not supporting the mechanism, at
   least 5 triggered request polls (without acknowledgement) should be
   sent.

   If a destination marked as not supporting the mechanism, subsequently
   sends a valid 'triggered' message, the destination should be marked
   as supporting the mechanism once more (to allow for the next hop
   router's configuration being changed).  It should be sent a triggered
   request and a triggered response to obtain and propagate up-to-date
   routing information.

2.8 Fragmentation

   If a routing update is sufficiently large, the information MUST be
   fragmented over several triggered response packets:

   o  Each fragment MUST be individually acknowledged with a triggered
      acknowledgement packet.

      The sender of the routing update MUST periodically retransmit
      fragments which have not been acknowledged (or until the
      destination is marked as not supporting the mechanism).

   o  A router receiving fragments MUST re-assemble them before
      updating its routing database.

   o  If all fragments are not received within four times the
      retransmit period, they MUST be discarded.

      A triggered request packet MUST then be sent to the originator
      of the routing update.

      On receiving the triggered request packet, the originator of the
      routing update MUST retransmit ALL fragments.

   o  If a fragment with an updated sequence number is received, ALL
      fragments with the earlier sequence number MUST be discarded.

      An updated sequence number is defined as any sequence number
      that is different.  There is no concept of the value of the
      sequence number conveying its age.



Meyer                                                          [Page 12]

RFC 1582                       Demand RIP                  February 1994


   Fragmentation timer values are covered in section 7.

2.9 Preventing Queue Overload

   In order to prevent too many routing messages being queued at a WAN
   interface, the routing task MAY operate a scheme whereby
   'broadcasting' of a triggered request or triggered response to a WAN
   interface is staggered.  All routing requests or routing responses
   are not sent to ALL next hop routers on the interface in a single
   batch:

   o  The routing task should limit the number of outstanding triggered
      request messages for which a triggered response has not been
      received.

   o  The routing task should limit the number of outstanding triggered
      response messages for which a triggered acknowledgement has not
      been received.

   As outstanding messages are appropriately acknowledged, further
   messages can be sent out to other next hop routers, until all next
   hop routers have been sent the message and have acknowledged it.

   The maximum number of outstanding messages transmitted without
   acknowledgement is a function of the link speed and the number of
   other routing protocols operating the triggered update mechanism.

   Messages should always be acknowledged immediately (even if it causes
   the limit to be exceeded), since a connection is almost certainly
   available.  This has the potential benefit of allowing the VC to
   close sooner (on its idle timer).

   Sending all triggered request fragments to a destination at once is
   also beneficial.

3. IP Routing Information Protocol Version 1

   This section should be read in conjunction with reference [1].

   IP RIP is a UDP-based protocol which generally sends and receives
   datagrams on UDP port number 520.

   To support the mechanism outlined in this proposal the packet format
   for RIP version 1 [1] is modified as shown in Figure 2.

   Every Routing Information Protocol datagram contains the following:





Meyer                                                          [Page 13]

RFC 1582                       Demand RIP                  February 1994


   COMMAND   Commands supported in RIP Version 1 are: request (1),
             response (2), traceon (3), traceoff (4), SUN reserved (5).
             The fields sequence number, fragment number and number of
             fragments MUST NOT be included in packets with these
             command values.

             The following new commands (with values in brackets) are
             required:

       TRIGGERED REQUEST (6)

                 A request for the responding system to send all of its
                 routing database.

                 Only the first 4 octets of the packet format shown in
                 figure 2 are sent, since all routing information is
                 implied by this request type.

       TRIGGERED RESPONSE (7)

                 A message containing all of the sender's routing
                 database, excluding those entries learned from the
                 interface to which the routing information is being
                 sent.

                 This message may be sent in response to a triggered
                 request, or it may be an update message resulting
                 from a change in the routing database.

                 A triggered response message MUST be sent in response
                 to a triggered request message even if there are no
                 routes to propagate.  This would be the case for a
                 host which had a WAN interface only, but which wished
                 to run the triggered update protocol.

     0                   1                   2                   3 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | command (1)   | version (1)   |      must be zero (2)         |
     +---------------+---------------+-------------------------------+

        The following new fields are inserted for some commands

     0                   1                   2                   3 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    sequence number (2)        | fragment (1)  |no of frags (1)|
     +-------------------------------+-------------------------------+



Meyer                                                          [Page 14]

RFC 1582                       Demand RIP                  February 1994


          Followed by up to 25 routing entries (each 20 octets)

     0                   1                   2                   3 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | address family identifier (2) |      must be zero (2)         |
     +-------------------------------+-------------------------------+
     |                         IP address (4)                        |
     +---------------------------------------------------------------+
     |                        must be zero (4)                       |
     +---------------------------------------------------------------+
     |                        must be zero (4)                       |
     +---------------------------------------------------------------+
     |                          metric (4)                           |
     +---------------------------------------------------------------+
                                     .
                                     .

     The format of an IP RIP datagram in octets, with each tick mark
     representing one bit.    All fields are in network order.

     The four octets: sequence number (2), fragment number (1) and
     number of fragments (1) are not present in the original RIP
     specification.  They are only present if command takes the
     values 7 or 8.


          Figure 2.   IP Routing Information Protocol packet format


       TRIGGERED ACKNOWLEDGEMENT (8)

                 A message sent in response to every triggered response
                 packet received.

                 Only the first 8 octets of the packet format shown in
                 figure 2 are sent.

   VERSION   In this instance Version 1.

   SEQUENCE NUMBER

             This is a new field inserted if command takes the values 7
             or 8.

             The sequence number MUST be incremented every time updated
             information is sent out on a WAN.  The sequence number
             wraps round at 65535.



Meyer                                                          [Page 15]

RFC 1582                       Demand RIP                  February 1994


             When a triggered acknowledgement is sent the sequence
             number is set to the same value as the triggered response
             packet being acknowledged.

             The sequence number MUST be identical over fragments.  If a
             fragment is retransmitted the sequence number MUST not
             change.

   FRAGMENT NUMBER

             The fragment number is one for the first fragment of a
             routing update, and is incremented for each subsequent
             fragment.  A fragment can contain up to 25 routing entries.

             When a triggered acknowledgement is sent the fragment
             number is set to the same value as the triggered response
             packet being acknowledged.

   NUMBER OF FRAGMENTS

             In a triggered response packet this indicates the number of
             packets required to complete the routing update.

             This field has no relevance for triggered acknowledgement
             packets so should be set to zero.

   For triggered response packets the rest of the datagram contains a
   list of destinations, with information about each.  Each entry in
   this list contains the address family identifier (2 for IP), a
   destination network or host, and the metric for it.  The packet
   format is intended to allow RIP to carry routing information for
   several different protocols, identifiable by the family identifier.

   The IP address is the usual Internet address, stored as 4 octets in
   network order.  The metric field contains a value between 1 and 15
   inclusive, specifying the current metric for the destination, or the
   value 16 (representing 'infinity'), which indicates that the
   destination is not reachable.  Each route sent by a router supersedes
   any previous route to the same destination from the same router.

   The maximum datagram size is 508 octets, excluding UDP and IP
   headers.

4. IP Routing Information Protocol Version 2

   An enhancement to IP RIP to include subnetting has recently become
   available [2].  This section only describes differences from that
   RFC.



Meyer                                                          [Page 16]

RFC 1582                       Demand RIP                  February 1994


   The triggered update mechanism can be supported by including the
   triggered request (6), triggered response (7) and triggered
   acknowledgement (8) commands described in the previous section.

   The sequence number, fragment number and number of fragments fields
   are included in triggered response and triggered acknowledgement
   commands.

   The triggered request packet should also contain the 4 extra octets
   corresponding to the sequence number, fragment number and number of
   fragments fields - but set to zero.

   Because additional security information is included in RIP Version 2
   packets, this MUST be appended to the triggered request and triggered
   acknowledgement packets, as well as being present in the triggered
   response packet.

   The version number becomes 2.  Other aspects of packet layout follow
   reference [2].

5. Netware Routing Information Protocol

   This section should be read in conjunction with references [3], since
   it only describes differences from the specification.

   Netware [3] is the trade name of Novell Research's protocols for
   computer communication which are derived and extended from Xerox
   Network System's (XNS) protocols [4].

   Netware supports a mechanism that allows routers on an internetwork
   to exchange routing information using the Routing Information
   Protocol (RIP) which runs over the Internetwork Packet Exchange (IPX)
   protocol using socket number 453h.

   Netware RIP and IP RIP share a common heritage, in that they are both
   based on XNS RIP, but there is some divergence, mostly at the packet
   format level to reflect the differing addressing schemes.

   The triggered update mechanism can be applied to Netware RIP.  To
   support the mechanism outlined in this proposal the packet format for
   Netware RIP is modified as shown in Figure 3.

   Every datagram contains the following:








Meyer                                                          [Page 17]

RFC 1582                       Demand RIP                  February 1994


   RIP OPERATION

             Operations supported in standard Netware RIP are: request
             (1) and response (2).

             The fields sequence number, fragment number and number of
             fragments MUST NOT be included in packets with these
             operation values.

             The following new operations are required (with values
             chosen to be the same as for IP RIP commands):

     0                   1         1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       operation (2)           |
     +---------------+---------------+

        The following new fields are inserted for some operations

     0                   1                   2                   3 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      sequence number (2)      | fragment (1)  |no of frags (1)|
     +-------------------------------+-------------------------------+

           Followed by up to 50 routing entries (each 8 octets)

     0                   1                   2                   3 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       network number (4)                      |
     +---------------------------------------------------------------+
     |       number of hops (2)      |      number of ticks (2)      |
     +---------------------------------------------------------------+
                                     .
                                     .

     The format of a Netware RIP datagram in octets, with each tick
     mark representing one bit.  All fields are in network order.

     The four octets: sequence number (2), fragment number (1) and
     number of fragments (1) are not present in the original RIP
     specification.  They are only present if operation takes the
     values 7 or 8.

        Figure 3.   Netware Routing Information Protocol packet format




Meyer                                                          [Page 18]

RFC 1582                       Demand RIP                  February 1994


       TRIGGERED REQUEST (6)

                 A request for the responding system to send all of its
                 routing database.

                 Only the first 2 octets of the packet format shown in
                 figure 3 are sent, since all routing information is
                 implied by this request type.

       TRIGGERED RESPONSE (7)

                 A message containing all of the sender's routing
                 database, excluding those entries learned from the
                 interface to which the routing information is being
                 sent.

                 This message may be sent in response to a triggered
                 request, or it may be an update message resulting
                 from a change in the routing database.

                 A triggered response message MUST be sent in response
                 to a triggered request message even if there are no
                 routes to propagate.  This would be the case for a
                 host which had a WAN interface only, but which wished
                 to run the triggered update protocol.

       TRIGGERED ACKNOWLEDGEMENT (8)

                 A message sent in response to every triggered
                 response packet received.

                 Only the first 6 octets of the packet format shown in
                 figure 3 are sent.

   SEQUENCE NUMBER

             This is a new field inserted if operation takes the
             values 7 or 8.

             The sequence number MUST be incremented every time
             updated information is sent out on a WAN.  The sequence
             number wraps round at 65535.

             When a triggered acknowledgement is sent the sequence
             number is set to the same value as the triggered response
             packet being acknowledged.





Meyer                                                          [Page 19]

RFC 1582                       Demand RIP                  February 1994


             The sequence number MUST be identical over fragments.  If
             a fragment is retransmitted the sequence number MUST not
             change.

   FRAGMENT NUMBER

             The fragment number is one for the first fragment of a
             routing update, and is incremented for each subsequent
             fragment.  A fragment can contain up to 50 routing entries.

             When a triggered acknowledgement is sent the fragment
             number is set to the same value as the triggered response
             packet being acknowledged.

   NUMBER OF FRAGMENTS

             In a triggered response packet this indicates the number
             of packets required to complete the routing update.

             This field has no relevance for triggered acknowledgement
             packets so should be set to zero.

   For triggered response packets the rest of the datagram contains a
   list of networks, with information about each.  Each entry in this
   list contains a destination network, and the number of hops and
   number of ticks for each.

   The maximum datagram size is 406 octets, excluding the IPX header (a
   further 30 octets).

6. Netware Service Advertising Protocol

   This section should be read in conjunction with references [3], since
   it only describes differences from the specification.

   Netware [3] also supports a mechanism that allows servers on an
   internetwork to advertise their services by name and type using the
   Service Advertising Protocol (SAP) which runs over the Internetwork
   Packet Exchange (IPX) protocol using socket number 452h.

   SAP operates on similar principals to running RIP.  Routers act as
   SAP agents, collecting service information from different networks
   and relay it to interested parties.

   To support the triggered update mechanism outlined in this proposal
   the packet format for Netware SAP is modified as shown in Figure 4.

   Every Service Advertising Protocol datagram contains the following:



Meyer                                                          [Page 20]

RFC 1582                       Demand RIP                  February 1994


   SAP OPERATION

             Operations supported in standard Netware SAP are: general
             service query (1), general service response (2), nearest
             service query (3) and nearest service response (4).

             The fields sequence number, fragment number and number of
             fragments MUST NOT be included in packets with these
             operation values.

             The following new operations are required:

       TRIGGERED GENERAL SERVICE QUERY (6)

                 A request for the responding system to send the
                 identities of all servers of all types.

                 Only the first 2 octets of the packet format shown in
                 figure 4 are sent, since all service types are
                 implied by this request type.

     0                   1         1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       operation (2)           |
     +---------------+---------------+

        The following new fields are inserted for some operations

     0                   1                   2                   3 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      sequence number (2)      | fragment (1)  |no of frags (1)|
     +-------------------------------+-------------------------------+

















Meyer                                                          [Page 21]

RFC 1582                       Demand RIP                  February 1994


           Followed by up to 8 service entries (each 66 octets)

     0                   1                   2                   3 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Service Type (4)                        |
     +---------------------------------------------------------------+
     |                       Service Name (48)                       |
     +                                                               +
                                  .
     |                            .                                  |
     +---------------------------------------------------------------+
     |                       Network Address (4)                     |
     +---------------------------------------------------------------+
     |                        Node Address (6)                       |
     +                               +-------------------------------+
     |                               |      Socket Address (2)       |
     +---------------------------------------------------------------+
     |       Hops to Server (2)      |
     +-------------------------------+
                                     .
                                     .

     The format of a Netware SAP datagram in octets, with each tick
     mark representing one bit.  All fields are in network order.

     The four octets: sequence number (2), fragment number (1) and
     number of fragments (1) are not present in the original SAP
     specification.  They are only present if operation takes the
     values 7 or 8.


        Figure 4.   Netware Service Advertising Protocol packet format


       TRIGGERED GENERAL SERVICE RESPONSE (7)

                 A message containing all of the sender's services
                 table, excluding those entries learned from the
                 interface to which the service advertising
                 information is being sent out.

                 This message may be sent in response to a triggered
                 general service query, or it may be an update message
                 resulting from a change in the service advertising
                 database.





Meyer                                                          [Page 22]

RFC 1582                       Demand RIP                  February 1994


                 A triggered general service response message MUST be
                 sent in response to a triggered general request
                 message even if there are no services to advertise.
                 This would be the case for a router with a LAN
                 network which had work stations but no servers on it.

       TRIGGERED GENERAL SERVICE ACKNOWLEDGEMENT (8)

                 A message sent in response to every triggered general
                 service response packet received.

                 Only the first 6 octets of the packet format shown in
                 figure 4 are sent.

   SEQUENCE NUMBER

             This is a new field inserted if operation takes the values
             7 or 8.

             The sequence number MUST be incremented every time updated
             information is sent out on a WAN.  The sequence number
             wraps round at 65535.

             When a triggered general service acknowledgement is sent
             the sequence number is set to the same value as the
             triggered general service response packet being
             acknowledged.

             The sequence number MUST be identical over fragments.  If
             a fragment is retransmitted the sequence number MUST not
             change.

   FRAGMENT NUMBER

             The fragment number is one for the first fragment of a
             triggered general service response update, and is
             incremented for each subsequent fragment.  A fragment can
             contain up to 8 service entries.

             When a triggered general service acknowledgement is sent,
             the fragment number is set to the same value as the
             triggered general service response packet being
             acknowledged.

   NUMBER OF FRAGMENTS

             In a triggered response packet this indicates the number of
             packets required to complete the service update.



Meyer                                                          [Page 23]

RFC 1582                       Demand RIP                  February 1994


             This field has no relevance for triggered acknowledgement
             packets so should be set to zero.

   For triggered general service response packets the rest of the
   datagram contains a list of services, with information about each.
   Each entry in this list contains the service type, service name, full
   address (network, node and socket), and the number of hops to the
   server.

   The maximum datagram size is 534 octets, excluding the IPX header (a
   further 30 octets).

7. Timers

   A number of timers are supported to handle the triggered update
   mechanism:

   o  Database timers.

   o  Retransmission timer.

   o  Reassembly timer.

   In this section appropriate timer values for IP RIP are suggested.

   For other routing protocols, only the database timer should need to
   take different values.  The database timer values are chosen to match
   equivalent timer operation for using the protocol on a LAN.  The
   behaviour of a routing entry when a timer is running becomes
   indistinguishable from a routing entry learned from a broadcast
   update.

   Implementations MAY make timer values configurable - and hence
   different from the values suggested here - but interoperability
   requires that all timers on a sub-network should be the same in all
   routers.

7.1 Database Timers

   Routes learned by a triggered response command (7) are normally
   considered to be permanent - that is they do NOT time out unless
   activated by one of the following events:

   o  If the circuit manager indicates that a next hop router cannot be
      contacted, all routes learned from that next hop router should
      start timing out as if they had (just) been learned from a
      conventional response command (2).




Meyer                                                          [Page 24]

RFC 1582                       Demand RIP                  February 1994


      Namely each route exists while the database entry timer is
      running and is advertised on other interfaces as if still
      present.  The route is then advertised as unreachable while a
      further hold down timer is allowed to expire, at which point the
      entry is deleted.

      If the circuit manager indicates that the next hop router can be
      contacted while the database entry timer is running, the routes
      are reinstated as permanent entries.

      If the database entry timer has expired and the circuit manager
      indicates that the next hop router is reachable, the routing
      application MUST issue a triggered request.  The routes will be
      reinstated on the basis of any triggered response packet(s)
      received.

   o  If a triggered response packet is received in which a route is
      marked unreachable, the hold down timer MUST be started and the
      entry is advertised as unreachable on other interfaces.  On
      expiry of the hold down timer the entry is deleted.

      If a triggered response packet is received in which an existing
      route is ABSENT, the hold down timer MUST also be started and
      the entry is advertised as unreachable on other interfaces.  On
      expiry of the hold down timer the entry is deleted.

   For IP RIP the hold down timer should always run for 120 seconds, to
   be consistent with RIP usage on broadcast networks.  The database
   entry timer should by default run for 180 seconds.  The network can
   be made more responsive by reducing the database entry timer value.
   However, making this timer too short can lead to network
   instabilities.  The duration of the database entry timer allows a
   period of grace in which contention for network resources can be
   resolved by the circuit manager.

7.2 Retransmission Timer

   The routing task runs a retransmission timer:

   o  When a triggered request is sent it will be retransmitted
      periodically while a triggered response packet is not received.

   o  When a triggered response is sent a note of the sequence number
      and fragment number(s) of the routing update is kept.

      Fragments will be retransmitted at periodic intervals while a
      triggered acknowledgement packet is not received for the
      appropriate fragment.



Meyer                                                          [Page 25]

RFC 1582                       Demand RIP                  February 1994


   With call set up time on the WAN being of the order of a second, a
   value of 5 seconds for the retransmission timer is appropriate.

   If no response is received after 10 retransmissions, routes via the
   next hop router are marked as unreachable, the hold down timer MUST
   be started and the entry is advertised as unreachable on other
   interfaces.  On expiry of the hold down timer the entry is deleted.

   The next hop router is then polled using a triggered request packet
   at 60 second intervals.  If a response is received the routers should
   exchange routing information using triggered response packets.

   It may not be desirable to poll indefinitely, since a lack of
   response (when a circuit is up) is most likely caused by incorrect
   configuration of the next hop router.  An administrator definable
   number of polls (5 or greater) should be provided.

   If the circuit manager indicates that the next hop router is
   unreachable, the retransmission is suppressed until the circuit
   manager indicates that the next hop router is reachable once more.
   Counting of the number of retransmissions continues from where it
   left off prior to the circuit down indication.

7.3 Reassembly Timer

   When a router receives a triggered response update it MUST
   acknowledge each fragment.  If the routing update is fragmented over
   more than one packet, the receiving router MUST store the fragments
   until ALL fragments are received.

   On receiving the first fragment a timer should be started.  If all
   fragments of the routing update are not received within that period
   they are discarded - and a triggered request is sent back to the
   originator (with retransmissions if necessary).  The originator MUST
   then resend ALL triggered response fragments.

   The reassembly timer should be set to four times the value of the
   retransmission timer.  With a suggested retransmission timer value of
   5 seconds, the suggested reassembly timer value SHOULD be 20 seconds.

   Implementations MAY allow the reassembly timer and retransmission
   timer to be configurable (in the 1:4 ratio), but interoperability
   will be compromised on WANs where all participating routers DO NOT
   support the same values for these timers.

   Fragments MUST also be discarded if a new fragment with a different
   sequence number is received.  A triggered request MUST not be sent in
   this instance.



Meyer                                                          [Page 26]

RFC 1582                       Demand RIP                  February 1994


8. Implementation Considerations

   In the implementation described in this memo, it is assumed that
   there is a close binding between the circuit manager and the routing
   applications - that they are in some way the same 'program'.  This is
   not necessarily true of all products which are routers.

   In particular there are UNIX host implementations in which the
   routing application is distinct from the kernel, where the circuit
   manager is likely to be installed.  In such systems it is possible to
   stop (or crash) the routing applications independently of what is
   happening in the kernel.

   Other implementations might have the circuit manager on a separate
   card which again may give the circuit manager a life of its own.

   In implementations where the applications and circuit manager have
   independent lives, a keep-alive mechanism MUST be provided between
   the applications and the circuit manager, so that if the application
   or network layer dies and is subsequently re-started they can
   resynchronize their state tables.

   Ideally, when an application dies, the circuit manager should close
   all existing VCs appropriate to the application and make no further
   outgoing calls and reject incoming calls until the application is
   running again.

   If the circuit manager is using some form of encapsulation, several
   applications may be sharing the same VC.  If this is the case the
   circuit manager may wish to filter out datagrams for the appropriate
   network layer if only one of the applications is affected.  But this
   is not an ideal solution.

   Conversely if the application believes the circuit manager has died,
   it should mark all routes via the circuit manager as unreachable and
   advertise them on other interfaces for the duration of the hold down
   timer before deleting them.

9. Security Considerations

   Security is provided my a number of aspects:

   o  The circuit manager is required to be provided with a list of
      physical addresses to enable it to establish a call to the next
      hop router on an X.25 SVC or ISDN B-channel.

      The circuit manager SHOULD only allow incoming calls to be
      accepted from the same well defined list of routers.



Meyer                                                          [Page 27]

RFC 1582                       Demand RIP                  February 1994


      Elsewhere in the system there will be a set of logical address
      and physical address tuples to enable the network protocols to
      run over the correct circuit.  This may be a lookup table, or in
      some instances there may be an algorithmic conversion between
      the two addresses.

   o  The routing (or service advertising) task MUST be provided with a
      list of logical addresses to which triggered updates are to be
      sent on the WAN.  The list MAY be a subset of the list of next
      hop routers maintained by the circuit manager.

      There MAY also be a separate list of next hop routers to which
      traditional broadcasts of routing (or service advertising)
      updates should be sent.  Next hop routers omitted from either
      list are assumed to be not participating in routing (or service
      advertising) updates.

      The list (or lists) doubles as a list of routers from which
      routing updates are allowed to be received from the WAN.  Any
      routing information received from a router not in the
      appropriate list MUST be discarded.

10. References

   [1] Hedrick. C., "Routing Information Protocol", STD 34, RFC 1058,
       Rutgers University, June 1988.

   [2] Malkin. G., "RIP Version 2 - Carrying Additional Information",
       RFC 1388, Xylogics, January 1993.

   [3] Novell Incorporated., "IPX Router Specification", Version 1.10,
       October 1992.

   [4] Xerox Corporation., "Internet Transport Protocols", Xerox System
       Integration Standard XSIS 028112, December 1981.

   [5] Malis. A., Robinson. D., and R. Ullmann, "Multiprotocol
       Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356, BBN
       Communications, Computervision Systems Integration, Process
       Software Corporation, August 1992.











Meyer                                                          [Page 28]

RFC 1582                       Demand RIP                  February 1994


11. Author's Address

       Gerry Meyer
       Spider Systems
       Stanwell Street
       Edinburgh EH6 5NG
       Scotland, UK

       Phone: (UK) 31 554 9424
       Fax:   (UK) 31 554 0649
       EMail: gerry@spider.co.uk








































Meyer                                                          [Page 29]