File: rfc2091.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 (1235 lines) | stat: -rw-r--r-- 44,835 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






Network Working Group                                           G. Meyer
Request for Comments: 2091                                         Shiva
Category: Standards Track                                      S. Sherry
                                                                  Xyplex
                                                            January 1997


         Triggered 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

   This document defines a modification which can be applied to
   Bellman-Ford (distance vector) algorithm information broadcasting
   protocols - for example IP RIP, Netware RIP or Netware SAP - which
   makes it feasible to run them on connection oriented Public Data
   Networks.

   This proposal has a number of efficiency advantages over the Demand
   RIP proposal (RFC 1582).

Acknowledgements

   The authors wish to thank Richard Edmonstone of Shiva, Joahanna
   Kruger of Xyplex, Steve Waters of DEC and Guenter Roeck of Conware
   for many comments and suggestions which improved this effort.

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
      circumstances.





Meyer & Sherry              Standards Track                     [Page 1]

RFC 2091                      Trigger RIP                   January 1997


   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 ...........................................  2
   2. Overview ...............................................  3
   3. The Routing Database ...................................  5
       3.1. Presumption of Reachability ......................  6
       3.2. Alternative Routes ...............................  6
       3.3. Split Horizon with Poisoned Reverse ..............  7
       3.4. Managing Updates .................................  7
       3.5. Retransmissions ..................................  7
   4. New Packet Types .......................................  8
       4.1. Update Request (9) ...............................  9
       4.2. Update Response (10) .............................  9
       4.3. Update Acknowledge (11) .......................... 10
   5. Packet Formats ......................................... 10
       5.1. Update Header .................................... 10
       5.2. IP Routing Information Protocol Version 1 ........ 11
       5.3. IP Routing Information Protocol Version 2 ........ 11
       5.4. Netware Routing Information Protocol ............. 12
       5.5. Netware Service Advertising Protocol ............. 12
   6. Timers ................................................. 17
       6.1. Database Timer ................................... 17
       6.2. Hold Down Timer .................................. 17
       6.3. Retransmission Timer ............................. 18
       6.4. Over-subscription Timer .......................... 18
   7. Security Considerations ................................ 19
   Appendix A - Implementation Suggestion .................... 20
   References ................................................ 21
   Authors' Addresses ........................................ 22

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.






Meyer & Sherry              Standards Track                     [Page 2]

RFC 2091                      Trigger RIP                   January 1997


   Periodic broadcasting by Bellman-Ford (distance vector) algorithm
   information broadcasting protocols IP RIP [1], IP RIP V2 [2] or
   Netware RIP and SAP [3] generally prevents WAN circuits from being
   closed.  Even on fixed point-to-point links the overhead of periodic
   transmission of RIP - and even more so SAP broadcasts - can seriously
   interrupt normal data transfer simply through the quantity of
   information which hits the line every 30 or 60 seconds.

   To overcome these limitations, this specification modifies the
   distance vector 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.

   The protocols run unmodified on Local Area Networks (LANs) and so
   interoperate transparently with implementations adhering to the
   original specifications.

   This proposal differs from Demand RIP [4] conceptually as follows:

   o  If a router has exchanged all routing information with its partner
      and some routing information subsequently changes only the changed
      information is sent to the partner.

   o  The receiver of routes is able to apply all changes immediately
      upon receiving information from a partner.

   These differences lead to further reduced routing traffic and also
   require less memory than Demand RIP [4].  Demand RIP also has an
   upper limit of 255 fragments in an update which is lifted in
   Triggered RIP (which does not use fragmentation).

2. 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.








Meyer & Sherry              Standards Track                     [Page 3]

RFC 2091                      Trigger RIP                   January 1997


   A circuit manager provides an interface between the connectionless
   network layers, IP and IPX, and the connection oriented WAN, X.25,
   ISDN etc.  Figure 1 shows a schematic representative stack 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.

   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 (or some
   other mechanism) is used to close the VC when the datagrams stop
   arriving at the circuit manager.





Meyer & Sherry              Standards Track                     [Page 4]

RFC 2091                      Trigger RIP                   January 1997


   If the circuit manager has data to forward (whether user data OR a
   routing update) and fails to obtain a VC it informs the routing
   application that the destination is unreachable (circuit down).  The
   circuit manager is then expected to perform whatever is necessary to
   recover the link.   Once successful, it informs the routing
   application (circuit up).

   In Triggered RIP, routing updates are only transmitted on the WAN
   when required:

   1  When a specific request for a routing update has been received.

   2  When the routing database is modified by new information from
      another interface.

   3  When the circuit manager indicates that a destination has changed
      from an unreachable (circuit down) to a reachable (circuit up)
      state.

   4  And also when a unit is first powered on to ensure that at least
      one update is sent.  This can be thought of as a transition from
      circuit down to circuit up.  It MAY contain no routes or services,
      and is used to flush routes or services from the peer's database.

   In cases 1,3 and 4 the full contents of the database is sent.  In
   case 2 only the latest changes are sent.

   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.

3. The Routing Database

   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.  Certain
   events can cause these routes to time out.











Meyer & Sherry              Standards Track                     [Page 5]

RFC 2091                      Trigger RIP                   January 1997


3.1 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
      reachable through an internal circuit down message.

      The database entries are first marked as temporary and aged
      normally; Some implementations may choose to omit this initial
      aging step.  The routing application then marks the appropriate
      database entries as unreachable for a hold down period (the normal
      120 second RIP hold down timer).

   o  If the circuit manager is subsequently able to establish a
      connection to the next hop router, it will notify the routing
      application 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.

   The next hop router may also be marked as unreachable if an excessive
   number of retransmissions of an update go unacknowledged (see section
   6.3).

   Handling of circuit up and circuit down messages requires that the
   circuit manager takes responsibility for establishing (or re-
   establishing) 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
   document.

3.2 Alternative Routes

   A requirement of using Triggered RIP for propagating routing
   information is that NO routing information ever gets LOST or
   DISCARDED.  This means that all alternative routes SHOULD be
   retained.

   It MAY be possible to operate with a sub-set of all alternative
   routes, but this adds complexity to the protocol - which is NOT
   covered in this document.




Meyer & Sherry              Standards Track                     [Page 6]

RFC 2091                      Trigger RIP                   January 1997


3.3 Split Horizon with Poisoned Reverse

   The rules for Split Horizon with Poisoned Reverse MUST be used to
   determine whether and/or how a route is advertised on an interface
   running this protocol.

   Split Horizon consists of omitting routes learned from a peer when
   sending updates back to that peer.  With Poisoned Reverse instead of
   omitting those routes, they are advertised as unreachable (setting
   the metric to infinity).

   A route is only poisoned if it is the best route (rather than an
   inferior alternative route) in the database.

   Poison Reverse is necessary because a router may be advertising a
   route to a network to its partner and then later learn a better route
   for the same network from the partner.  Without Poison Reverse the
   partner will not know to discard the inferior route learned from the
   first router.

3.4 Managing Routing Updates

   The routing database SHOULD be considered to be a sequence of
   elements ordered by the time it was last updated.  If there is a
   change in the best route (i.e. a new route is added or a route's
   metric has changed), the route is reordered and given a new highest
   sequence number.

   Sending updates to a peer consists of running through the database
   from the oldest entry to the newest entry.  Once an entry has been
   sent and acknowledged it is generally never resent.  As new routing
   information arrives, only the new information is sent.

3.5 Retransmissions

   Handling retransmission of updates is simplest if updates are
   restricted to never having more than one un-acknowledged update
   outstanding - "one packet in flight".  A copy of the update packet
   can be kept and retransmitted until acknowledged - and then
   subsequent update packets are sent in turn until the full database
   (to date) has been sent and acknowledged.










Meyer & Sherry              Standards Track                     [Page 7]

RFC 2091                      Trigger RIP                   January 1997


   Things become more complicated if several packets are sent in quick
   succession without waiting for an acknowledgements between packets -
   "several packets in flight":

   o  If packets arrive out of order they could corrupt the peer's
      database.  If the underlying datalink layer bundles several VCs,
      it MUST guarantee to NOT reorder datagrams.

   o  If the elements making up a packet requiring retransmission change
      because of an alteration in the database, stale incorrect
      information could be sent (again new information could overtake
      old information).

   To guard against this when 'retransmitting' a packet when the
   database is in flux the packet MUST be re-created from the database
   to contain only the subset of routes which currently apply.  And if
   none of the routes still apply, nothing will be 'retransmitted'.

   For simplicity of implementation we would advise having only one
   packet in flight.  However if the 'round trip' for a response and
   acknowledgement is quite long this could significantly delay large
   updates.  See Appendix A for an understanding of the additional
   complexity of managing several packets in flight.

4. New Packet Types

   To support triggered updates, three new packet types MUST be
   supported.  For IP RIP Version 1 [1] and IP RIP Version 2 [2] these
   are identified by the Command Field values shown:

      o  9 - Update Request

      o  10 - Update Response

      o  11 - Update Acknowledge

   For Netware RIP and SAP [3] the equivalent Field to distinguish
   between packet types is called Operation and these take the same
   values.

   These Command and Operation types require the addition of a 4 octet
   Update header.  All three packet types contain a Version, which MUST
   be 1.  Update Response and Update Acknowledge also have a Sequence
   Number and a Flush Flag.







Meyer & Sherry              Standards Track                     [Page 8]

RFC 2091                      Trigger RIP                   January 1997


4.1 Update Request

   The Update Request has the Command/Operation value 9.

   It is a request to the peer system to send ALL appropriate elements
   in its routing database.  It is retransmitted at periodic intervals
   (every 5 seconds) until an Update Response message is received with
   the Flush flag set.

   An Update Request is 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 and changes to a reachable
      (circuit up) state.

   An Update Request may also be sent at other times to compensate for
   discarding non-optimal routing information or if an Update Response
   continues to be unacknowledged (see section 6.3).

4.2 Update Response

   The Update Response has the Command/Operation value 10.

   It is a message containing zero or more routes in an update.  It is
   retransmitted at periodic intervals until an Update Acknowledge is
   received.

   An Update Response message MUST be sent:

   o  In response to an Update Request.  The Update Response MUST have
      the Flush flag set.  Other Update Responses should NOT be sent
      until an Update Acknowledge has been received acknowledging the
      Flush flag.

      The remainder of the database MUST then be sent as a series of
      Update Responses with the Flush flag NOT set.

   o  An Update Response with the Flush flag set MUST also be sent at
      power on to flush the peer's routing table learned from a previous
      incarnation.  This Update Response SHOULD NOT contain any routes.
      This avoids any possibility of an acknowledgement being received
      to a response sent BEFORE the unit was restarted causing confusion
      about which routes are being acknowledged.

   Update Response messages continue to be sent any time there is fresh
   routing information to be propagated.



Meyer & Sherry              Standards Track                     [Page 9]

RFC 2091                      Trigger RIP                   January 1997


   Each new Update Response is given a different Sequence Number.  The
   Sequence Number only has 'meaning' to the sender of the Update
   Response.  The same Update Response sent to different peers MAY have
   a different Sequence Number.

   An Update Response packet with the Flush flag set MUST be sent to a
   peer:

      o  At power on.

      o  In response to an Update Request packet.

      o  After transitioning from a circuit down to a circuit up state.

   After sending an Update Flush, the full database MUST be sent
   subsequently.

4.3 Update Acknowledge

   The Update Acknowledge has the Command/Operation value 11.

   It is a message sent in response to every Update Response packet
   received.  If the Update Response packet has the flush flag set then
   so should the Update Acknowledge packet.

5. Packet Formats

5.1 Update Header

   To support the mechanism outlined in this proposal the packet format
   for RIP Version 1 [1], RIP Version 2 [2] and Netware RIP and SAP [3]
   are modified to include an additional small header when using
   Commands Update Request (9), Update Response (10) and Update
   Acknowledge (11).  Commands are called Operations in Netware.

   Update Request (9):

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Version (1)  |               must be zero (3)                |
     +-------------------------------+-------------------------------+









Meyer & Sherry              Standards Track                    [Page 10]

RFC 2091                      Trigger RIP                   January 1997


     Update Response (10) and Update Acknowledge (11):

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Version (1)  |   Flush (1)   |     Sequence Number (2)       |
     +-------------------------------+-------------------------------+


     Four octet Update headers, with each  tick  mark  representing  one
     bit.  All fields are coded in network byte order (big-endian).


                         Figure 2.   Update Headers.

   Version MUST be 1 in all headers.  Any packets received for a
   different Version MUST be silently discarded.

   The Sequence Number MUST be incremented every time a new Update
   Response packet is sent on the WAN.  The Sequence Number is unchanged
   for retransmissions.  The Sequence Number wraps round at 65535.

   Flush is set to 1 in an Update Response if the peer is required to
   start timing out its entries - otherwise it is set to zero.  Any
   other values MUST be silently discarded.

   The peer returns an Update Acknowledge containing the same Sequence
   Number and Flush.

5.2 IP Routing Information Protocol Version 1

   IP RIP [1] 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 when using Commands Update Request
   (9), Update Response (10) and Update Acknowledge (11).  See Figure 3.

5.3 IP Routing Information Protocol Version 2

   IP RIP Version 2 [2] is an enhancement to IP RIP Version 1 which
   allows RIP updates to include subnetting information.

   To support the mechanism outlined in this proposal the packet format
   for RIP Version 2 [2] is modified when using Commands Update Request
   (9), Update Response (10) and Update Acknowledge (11).  See Figure 4.





Meyer & Sherry              Standards Track                    [Page 11]

RFC 2091                      Trigger RIP                   January 1997


5.4 Netware Routing Information Protocol

   Netware [3] 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.

   To support the mechanism outlined in this proposal the packet format
   for Novell RIP [3] is modified when using Operations Update Request
   (9), Update Response (10) and Update Acknowledge (11).  See Figure 5.

5.5 Netware Service Advertising Protocol

   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 mechanism outlined in this proposal the packet format
   for Novell SAP [3] is modified when using Operations Update Request
   (9), Update Response (10) and Update Acknowledge (11).  See Figure 6.

     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)   | RIP Version (1)|     must be zero (2)         |
     +---------------+---------------+-------------------------------+

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Update Header (4)                         |
     +-------------------------------+-------------------------------+















Meyer & Sherry              Standards Track                    [Page 12]

RFC 2091                      Trigger RIP                   January 1997


     Update Response then has 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 coded in network byte order
     (big-endian).

     The four octets of the Update header are included in Update Request
     (Command  9),  Update  Response  (10)  and  Update Acknowledge (11)
     packets.  They are not present in packet types in the original  RIP
     Version 1 specification.

                  Figure 3.   IP RIP Version 1 packet format























Meyer & Sherry              Standards Track                    [Page 13]

RFC 2091                      Trigger RIP                   January 1997


     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)   |RIP Version (1)|      must be zero (2)         |
     +---------------+---------------+-------------------------------+

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Update Header (4)                         |
     +-------------------------------+-------------------------------+

     Update Response then has 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) |        Route Tag (2)          |
     +-------------------------------+-------------------------------+
     |                         IP address (4)                        |
     +---------------------------------------------------------------+
     |                         Subnet Mask (4)                       |
     +---------------------------------------------------------------+
     |                         Next Hop (4) - must be zero           |
     +---------------------------------------------------------------+
     |                         Metric (4)                            |
     +---------------------------------------------------------------+
                                     .
                                     .

     The format of an IP RIP Version 2 datagram  in  octets,  with  each
     tick  mark  representing  one bit.  All fields are coded in network
     byte order (big-endian).

     The four octets of the Update header are included in Update Request
     (Command  9),  Update  Response  (10)  and  Update Acknowledge (11)
     Packets.  They are not present in packet types in the original  RIP
     Version 2 specification.

     Next Hop MUST be zero, since Triggered RIP can NOT advertise routes
     on behalf of other WAN routers.

     If authentication is used it immediately follows the Update header.

                  Figure 4.   IP RIP Version 2 packet format






Meyer & Sherry              Standards Track                    [Page 14]

RFC 2091                      Trigger RIP                   January 1997


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

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Update Header (4)                         |
     +-------------------------------+-------------------------------+

     Update Response then has 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 coded in network byte order
     (big-endian).

     The four octets of the Update header are included in Update Request
     (Operation  9),  Update  Response  (10) and Update Acknowledge (11)
     packets.  They are not present in  packet  types  in  the  original
     Novell RIP specification.

                    Figure 5.   Netware RIP packet format

















Meyer & Sherry              Standards Track                    [Page 15]

RFC 2091                      Trigger RIP                   January 1997


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

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Update Header (4)                         |
     +-------------------------------+-------------------------------+

     Update Response then has up to 8 service entries (each 64 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 (2)       |                               |
     +-------------------------------+                               |
     |                       Service Name (48)                       |
     |                            .                                  |
                                  .
                                  .  +-------------------------------+
     |                            .  | Network Address (4)           |
     +-------------------------------+-------------------------------+
     |  Network Address (cont)       |                               |
     +-------------------------------+                               |
     |                        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 coded in network byte order
     (big-endian).

     The four octets of the Update header are included in Update Request
     (Operation  9),  Update  Response  (10) and Update Acknowledge (11)
     packets.  They are not present in  packet  types  in  the  original
     Novell SAP specification.


                    Figure 6.   Netware SAP packet format






Meyer & Sherry              Standards Track                    [Page 16]

RFC 2091                      Trigger RIP                   January 1997


6. Timers

   Three timers are supported to handle the triggered update mechanism:

   o  Database timer.

   o  Hold down timer.

   o  Retransmission timer.

   An optional over-subscription timer MAY also be supported.

6.1 Database Timer

   Routes learned by an Update Response are normally considered to be
   permanent.

   When an Update Response with the Flush flag set is received, 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).

   Namely each route exists while the database entry timer (usually 180
   seconds) 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.

6.2 Hold down Timer

   A hold down timer of 120 seconds is started on a route:

   o  When the database timer for the route expires.

   o  When a formerly reachable route changes to unreachable in an
      incoming response.

   o  When a circuit down is received from the circuit manager.

   While the hold down timer is running routes are advertised as
   unreachable on other interfaces.

   When the hold down timer expires the route MAY be deleted from the
   database PROVIDING its unreachability has been successfully
   propagated to all WAN destinations, or the remaining WAN destinations
   are in a circuit down state.  If a route can not be deleted when the
   hold-down timer expires, it MAY subsequently be deleted when each and
   every peer is either up-to-date or is in a circuit down state.




Meyer & Sherry              Standards Track                    [Page 17]

RFC 2091                      Trigger RIP                   January 1997


   If the hold down timer is already running it is NOT reset by any
   events which would start the hold down timer.

6.3 Retransmission Timer

   The routing task runs a retransmission timer:

   o  An Update Request packet is retransmitted periodically until an
      Update Flush packet is received.  An Update Flush packet is an
      Update Response packet with the Flush field set.  It need not
      contain routes.

   o  An Update Response packet is retransmitted periodically until an
      Update Acknowledge packet is received containing the same Sequence
      Number.

   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.

   To prevent against failures in the circuit manager a limit SHOULD be
   placed on the number of retransmissions. If no response has been
   received after a configurable length of time (say 180 seconds) routes
   via the next hop router are marked as unreachable, the hold down
   timer is started and the entry is advertised as unreachable on other
   interfaces.

   The next hop router may then be polled with Update Requests at a
   reduced frequency.  A suitable poll interval would be of the order of
   minutes rather than seconds.  Alternatively an Update Request could
   be initiated by administrative action.  When a response is received
   the routers should perform a complete exchange of routing
   information.

6.4 Over-subscription Timer

   Over-subscription is where there are more next hop routers to send
   updates to on the WAN than there are channels.  For example 3 next
   hop routers accessed by an ISDN Basic Rate Interface (BRI) which can
   only support 2 calls simultaneously.

   To avoid route oscillation routes may NOT be marked unreachable
   immediately on receiving a circuit down message from the circuit
   manager.  A timeout MAY be used to delay marking the routes
   unreachable for sufficiently long to allow the calls to 'time
   division multiplex' over the available channels.  A timeout as long
   as the regular 180 second RIP route timeout MAY be suitable.  In
   general the greater the over-subscription, the longer the time out
   should be.



Meyer & Sherry              Standards Track                    [Page 18]

RFC 2091                      Trigger RIP                   January 1997


   Implementations wishing to support over-subscription may implement
   the delay within the circuit manager or within the routing
   application.

   If the delay is implemented within the routing application the
   routing entries MUST NOT start timing out during  the delay.  This
   allows the circuit up message to be ignored if the timeout after
   receiving the circuit down has still to expire.  This avoids any
   confusion if the peer had previously issued a Route Flush command and
   was part way through an update.

7. Security Considerations

   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.  The circuit manager SHOULD only allow incoming calls to be
   accepted from the same well defined list of routers.

   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.

   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.

   RIP Version 2 also allows further authentication of Triggered RIP
   packets.




















Meyer & Sherry              Standards Track                    [Page 19]

RFC 2091                      Trigger RIP                   January 1997


Appendix A - Implementation Suggestion

   This section suggests how the database might be structured to handle
   Triggered RIP.

   Each entry in the database is given a unique route number.  Every
   time a best route to a network changes, a global route number is
   incremented and the changed route is given the new route number.
   Note that this route number is completely internal to the router and
   has no bearing on the Sequence Number sent in Update Responses sent
   to the peer.

   The route number size should be large enough so as not to wrap round
   - or the routes can be renumbered before it becomes a problem.  Re-
   numbering requires that the database environment is stable (No Update
   Responses are queued awaiting Acknowledgement)

   Is is probably easier to manage the routes if they are also chained
   together using a pointer to a later (and possibly also a pointer to
   an earlier) entry which reflect the route number/age.

   Performing a complete update then consists of running though the
   routes from the oldest to the latest and sending them out in Update
   Responses.  Subsequent changes to the database are treated as sending
   out only the changed entries (from the previous latest to the new
   latest).

   When allowing for several packets in flight care must be taken with
   retransmissions.  An Update Response 'retransmission' MAY be
   different from the original.  When transmitting a sequence of Update
   Responses each Response packet contains a number of routes which is a
represented by a series of routes with consecutive route numbers.
   Consider sending three Update Responses with Sequence numbers 10,11
   and 12 each containing 10 routes:

   Sequence Number    Routes represented by Route Numbers

         10           101, 102, 103, 104, 105, 106, 107, 108, 109, 110

         11           111, 112, 113, 114, 115, 116, 117, 118, 119, 120

         12           121, 122, 123, 124, 125, 126, 127, 128, 129, 130









Meyer & Sherry              Standards Track                    [Page 20]

RFC 2091                      Trigger RIP                   January 1997


   If these Update Responses are NOT acknowledged, but in the meantime
   the routing database has changed and the routes represented by route
   numbers 104, 112 - 116 and 127 have changed and been assigned new
   route numbers 131 - 137, the retransmission will look like:

           Sequence Number    Routes represented by Route Numbers

            10           101, 102, 103, 105, 106, 107, 108, 109, 110

            11           111, 117, 118, 119, 120

            12           121, 122, 123, 124, 125, 126, 128, 129, 130

            13           131, 132, 133, 134, 135, 136, 137

      To perform a retransmission it is VERY IMPORTANT that the
      retransmission contains only the SUB-SET of route numbers which
      currently apply.  If there are NO suitable routes to send, it is not
      necessary to send an empty retransmission.

   An alternative 'retransmission' strategy is to always use different
   sequence numbers when resending updates.  Consider transmitting
   packets with sequence numbers 10 through 20 - and responses are
   received from all packets except those with sequence numbers 14 and
   17.  In this case only the data in packets 10 through 13 can be
   considered to be acknowledged.  The data from packet 14 onwards MUST
   be re-sent and given new sequence numbers starting at 21.

References

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

   [2]  Malkin. G., "RIP Version 2 - Carrying Additional Information",
        RFC 1723, Xylogics, November 1994.

   [3]  Novell Incorporated., "IPX Router Specification", Version 1.20,
        October 1993.

   [4]  Meyer. G., "Extensions to RIP to Support Demand Circuits",
        Spider Systems, February 1994.










Meyer & Sherry              Standards Track                    [Page 21]

RFC 2091                      Trigger RIP                   January 1997


Authors'  Address:

   Gerry Meyer
   Shiva
   Stanwell Street
   Edinburgh EH6 5NG
   Scotland, UK

   Phone: (UK) 131 554 9424
   Fax:   (UK) 131 467 7749
   Email: gerry@europe.shiva.com

   Steve Sherry
   Xyplex
   295 Foster St.
   Littleton, MA 01460

   Phone: (US) 508 952 4745
   Fax:   (US) 508 952 4887
   Email: shs@xyplex.com































Meyer & Sherry              Standards Track                    [Page 22]