idnits 2.17.1 draft-ietf-rip-trigger-rip-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 57: '... o MUST -- the item is an absolute ...' RFC 2119 keyword, line 58: '... MUST is only used where it is ac...' RFC 2119 keyword, line 62: '... o SHOULD -- the item should be fol...' RFC 2119 keyword, line 65: '... o MAY or optional -- the item is t...' RFC 2119 keyword, line 228: '... circuit up. It MAY contain no routes...' (34 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 188 has weird spacing: '...er will suppo...' == Line 483 has weird spacing: '...th each tick ...' == Line 575 has weird spacing: '..., with each ...' == Line 576 has weird spacing: '...senting one ...' == Line 616 has weird spacing: '...atagram in o...' == (6 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Jan 1996) is 10327 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Historic RFC: RFC 1058 (ref. '1') ** Obsolete normative reference: RFC 1723 (ref. '2') (Obsoleted by RFC 2453) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G.M. Meyer 3 Internet Draft Shiva 4 Expires 2 Aug 1996 S. Sherry 5 Xyplex 6 Jan 1996 8 Triggered Extensions to RIP to Support Demand Circuits 9 draft-ietf-rip-trigger-rip-01.txt 11 Status of this Memo 13 This document is a submission to the RIP Working Group of the 14 Internet Engineering Task Force (IETF). Comments should be submitted 15 to the ietf-rip@xylogics.com mailing list. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft. Internet Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its Areas, 21 and its Working Groups. Note that other groups may also distribute 22 working documents as Internet Drafts. 24 Internet Drafts are draft documents valid for a maximum of six 25 months, and may be updated, replaced, or obsoleted by other documents 26 at any time. It is not appropriate to use Internet Drafts as 27 reference material, or to cite them other than as a ``working draft'' 28 or ``work in progress.'' 30 To learn the current status of any Internet-Draft, please check the 31 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 32 Directories on ds.internic.net (US East Coast), nic.nordu.net 33 Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 35 Abstract 37 This document defines a modification which can be applied to 38 Bellman-Ford (distance vector) algorithm information broadcasting 39 protocols - for example IP RIP, Netware RIP or Netware SAP - which 40 makes it feasible to run them on connection oriented Public Data 41 Networks. 43 This proposal has a number of efficiency advantages over the Demand 44 RIP proposal (RFC 1582). 46 Acknowledgements 48 The authors wish to thank Richard Edmonstone of Shiva, Joahanna 49 Kruger of Xyplex, Steve Waters of DEC and Guenter Roeck of Conware 50 for many comments and suggestions which improved this effort. 52 Conventions 54 The following language conventions are used in the items of 55 specification in this document: 57 o MUST -- the item is an absolute requirement of the specification. 58 MUST is only used where it is actually required for interopera- 59 tion, not to try to impose a particular method on implementors 60 where not required for interoperability. 62 o SHOULD -- the item should be followed for all but exceptional cir- 63 cumstances. 65 o MAY or optional -- the item is truly optional and may be followed 66 or ignored according to the needs of the implementor. 68 The words "should" and "may" are also used, in lower case, in 69 their more ordinary senses. 71 Table of Contents 73 1. Introduction ........................................... 4 75 2. Overview ............................................... 5 77 3. The Routing Database ................................... 7 78 3.1. Presumption of Reachability ...................... 7 79 3.2. Alternative Routes ............................... 8 80 3.3. Split Horizon with Poisoned Reverse .............. 8 81 3.4. Managing Updates ................................. 8 82 3.5. Retransmissions .................................. 9 84 4. New Packet Types ....................................... 10 85 4.1. Update Request (9) ............................... 10 86 4.2. Update Response (10) ............................. 11 87 4.3. Update Acknowledge (11) .......................... 12 89 5. Packet Formats ......................................... 13 90 5.1. Update Header .................................... 13 91 5.2. IP Routing Information Protocol Version 1 ........ 14 92 5.3. IP Routing Information Protocol Version 2 ........ 14 93 5.4. Netware Routing Information Protocol ............. 14 94 5.5. Netware Service Advertising Protocol ............. 14 96 6. Timers ................................................. 19 97 6.1. Database Timer ................................... 19 98 6.2. Hold Down Timer .................................. 19 99 6.3. Retransmission Timer ............................. 20 100 6.4. Over-subscription Timer .......................... 20 102 7. Security Considerations ................................ 21 104 Appendix A - Implementation Suggestion .................... 21 106 1. Introduction 108 Routers are used on connection oriented networks, such as X.25 packet 109 switched networks and ISDN networks, to allow potential connectivity 110 to a large number of remote destinations. Circuits on the Wide Area 111 Network (WAN) are established on demand and are relinquished when the 112 traffic subsides. Depending on the application, the connection 113 between any two sites for user data might actually be short and 114 relatively infrequent. 116 Periodic broadcasting by Bellman-Ford (distance vector) algorithm 117 information broadcasting protocols IP RIP [1], IP RIP V2 [2] or 118 Netware RIP and SAP [3] generally prevents WAN circuits from being 119 closed. Even on fixed point-to-point links the overhead of periodic 120 transmission of RIP - and even more so SAP broadcasts - can seriously 121 interrupt normal data transfer simply through the quantity of 122 information which hits the line every 30 or 60 seconds. 124 To overcome these limitations, this specification modifies the 125 distance vector protocols so as to send information on the WAN only 126 when there has been an update to the routing database OR a change in 127 the reachability of a next hop router is indicated by the task which 128 manages connections on the WAN. 130 Because datagrams are not guaranteed to get through on all WAN media, 131 an acknowledgement and retransmission system is required to provide 132 reliability. 134 The protocols run unmodified on Local Area Networks (LANs) and so 135 interoperate transparently with implementations adhering to the 136 original specifications. 138 This proposal differs from Demand RIP [4] conceptually as follows: 140 o If a router has exchanged all routing information with its partner 141 and some routing information subsequently changes only the changed 142 information is sent to the partner. 144 o The receiver of routes is able to apply all changes immediately 145 upon receiving information from a partner. 147 These differences lead to further reduced routing traffic and also 148 require less memory than Demand RIP [4]. Demand RIP also has an 149 upper limit of 255 fragments in an update which is lifted in 150 Triggered RIP (which does not use fragmentation). 152 2. Overview 154 Multiprotocol routers are used on connection oriented Wide Area 155 Networks (WANs), such as X.25 packet switched networks and ISDN 156 networks, to interconnect LANs. By using the multiplexing properties 157 of the underlying WAN technology, several LANs can be interconnected 158 simultaneously through a single physical interface on the router. 160 A circuit manager provides an interface between the connectionless 161 network layers, IP and IPX, and the connection oriented WAN, X.25, 162 ISDN etc. Figure 1 shows a schematic representative stack showing 163 the relationship between routing protocols, the network layers, the 164 circuit manager and the connection oriented WAN. 166 -------------- --------- --------- 167 | RIP | | RIP | | SAP | 168 -------------- --------- --------- 169 | | | 170 -------------- | | 171 | UDP | | | 172 -------------- | | 173 | | | 174 -------------- ---------------- 175 | IP | | IPX | 176 -------------- ---------------- 177 | | 178 ------------------------------------------- 179 | Circuit Manager | 180 ------------------------------------------- 181 |||||||||| 182 |||||||||| 183 --------------------------- 184 | Connection Oriented | 185 | WAN stack | 186 --------------------------- 188 A WAN circuit manager will support a variety of network layer 189 protocols, on its upper interface. On its lower interface, it may 190 support one or more subnetworks. A subnetwork may support a number 191 of Virtual Circuits. 193 Figure 1. Representative Multiprotocol Router stack 195 The router has a translation table which relates the network layer 196 address of the next hop router to the physical address used to 197 establish a Virtual Circuit (VC) to it. 199 The circuit manager takes datagrams from the connectionless network 200 layer protocols and (if one is not currently available) opens a VC to 201 the next hop router. A VC can carry all traffic between two end- 202 point routers for a given network layer protocol (or with appropriate 203 encapsulation all network layer protocols). An idle timer (or some 204 other mechanism) is used to close the VC when the datagrams stop 205 arriving at the circuit manager. 207 If the circuit manager has data to forward (whether user data OR a 208 routing update) and fails to obtain a VC it informs the routing 209 application that the destination is unreachable (circuit down). The 210 circuit manager is then expected to perform whatever is necessary to 211 recover the link. Once successful, it informs the routing 212 application (circuit up). 214 In Triggered RIP, routing updates are only transmitted on the WAN 215 when required: 217 1 When a specific request for a routing update has been received. 219 2 When the routing database is modified by new information from 220 another interface. 222 3 When the circuit manager indicates that a destination has changed 223 from an unreachable (circuit down) to a reachable (circuit up) 224 state. 226 4 And also when a unit is first powered on to ensure that at least 227 one update is sent. This can be thought of as a transition from 228 circuit down to circuit up. It MAY contain no routes or services, 229 and is used to flush routes or services from the peer's database. 231 In cases 1,3 and 4 the full contents of the database is sent. In 232 case 2 only the latest changes are sent. 234 Because of the inherent unreliability of a datagram based system, 235 both routing requests and routing responses require acknowledgement, 236 and retransmission in the event of NOT receiving an acknowledgement. 238 3. The Routing Database 240 Entries in the routing database can either be permanent or temporary. 241 Entries learned from broadcasts on LANs are temporary. They will 242 expire if not periodically refreshed by further broadcasts. 244 Entries learned from a triggered response on the WAN are 'permanent'. 245 They MUST not time out in the normal course of events. Certain 246 events can cause these routes to time out. 248 3.1 Presumption of Reachability 250 If a routing update is received from a next hop router on the WAN, 251 entries in the update are thereafter always considered to be 252 reachable, unless proven otherwise: 254 o If in the normal course of routing datagrams, the circuit manager 255 fails to establish a connection to the next hop router, it 256 notifies the routing application that the next hop router is not 257 reachable through an internal circuit down message. 259 The database entries are first marked as temporary and aged 260 normally; Some implementations may choose to omit this initial 261 aging step. The routing application then marks the appropriate 262 database entries as unreachable for a hold down period (the normal 263 120 second RIP hold down timer). 265 o If the circuit manager is subsequently able to establish a 266 connection to the next hop router, it will notify the routing 267 application that the next hop router is reachable through an 268 internal circuit up message. 270 The routing application will then exchange messages with the next 271 hop router so as to re-prime their respective routing databases 272 with up-to-date information. 274 The next hop router may also be marked as unreachable if an excessive 275 number of retransmissions of an update go unacknowledged (see section 276 6.3). 278 Handling of circuit up and circuit down messages requires that the 279 circuit manager takes responsibility for establishing (or re- 280 establishing) the connection in the event of a next hop router 281 becoming unreachable. A description of the processes the circuit 282 manager adopts to perform this task is outside the scope of this 283 document. 285 3.2 Alternative Routes 287 A requirement of using Triggered RIP for propagating routing 288 information is that NO routing information ever gets LOST or 289 DISCARDED. This means that all alternative routes SHOULD be 290 retained. 292 It MAY be possible to operate with a sub-set of all alternative 293 routes, but this adds complexity to the protocol - which is NOT 294 covered in this document. 296 3.3 Split Horizon with Poisoned Reverse 298 The rules for Split Horizon with Poisoned Reverse MUST be used to 299 determine whether and/or how a route is advertised on an interface 300 running this protocol. 302 Split Horizon consists of omitting routes learned from a peer when 303 sending updates back to that peer. With Poisoned Reverse instead of 304 omitting those routes, they are advertised as unreachable (setting 305 the metric to infinity). 307 A route is only poisoned if it is the best route (rather than an 308 inferior alternative route) in the database. 310 Poison Reverse is necessary because a router may be advertising a 311 route to a network to its partner and then later learn a better route 312 for the same network from the partner. Without Poison Reverse the 313 partner will not know to discard the inferior route learned from the 314 first router. 316 3.4 Managing Routing Updates 318 The routing database SHOULD be considered to be a sequence of 319 elements ordered by the time it was last updated. If there is a 320 change in the best route (i.e. a new route is added or a route's 321 metric has changed), the route is reordered and given a new highest 322 sequence number. 324 Sending updates to a peer consists of running through the database 325 from the oldest entry to the newest entry. Once an entry has been 326 sent and acknowledged it is generally never resent. As new routing 327 information arrives, only the new information is sent. 329 3.5 Retransmissions 331 Handling retransmission of updates is simplest if updates are 332 restricted to never having more than one un-acknowledged update 333 outstanding - "one packet in flight". A copy of the update packet 334 can be kept and retransmitted until acknowledged - and then 335 subsequent update packets are sent in turn until the full database 336 (to date) has been sent and acknowledged. 338 Things become more complicated if several packets are sent in quick 339 succession without waiting for an acknowledgements between packets - 340 "several packets in flight": 342 o If packets arrive out of order they could corrupt the peer's 343 database. If the underlying datalink layer bundles several VCs, 344 it MUST guarantee to NOT reorder datagrams. 346 o If the elements making up a packet requiring retransmission change 347 because of an alteration in the database, stale incorrect 348 information could be sent (again new information could overtake 349 old information). 351 To guard against this when 'retransmitting' a packet when the 352 database is in flux the packet MUST be re-created from the database 353 to contain only the subset of routes which currently apply. And if 354 none of the routes still apply, nothing will be 'retransmitted'. 356 For simplicity of implementation we would advise having only one 357 packet in flight. However if the 'round trip' for a response and 358 acknowledgement is quite long this could significantly delay large 359 updates. See Appendix A for an understanding of the additional 360 complexity of managing several packets in flight. 362 4. New Packet Types 364 To support triggered updates, three new packet types MUST be 365 supported. For IP RIP Version 1 [1] and IP RIP Version 2 [2] these 366 are identified by the Command Field values shown: 368 o 9 - Update Request 370 o 10 - Update Response 372 o 11 - Update Acknowledge 374 For Netware RIP and SAP [3] the equivalent Field to distinguish 375 between packet types is called Operation and these take the same 376 values. 378 These Command and Operation types require the addition of a 4 octet 379 Update header. All three packet types contain a Version, which MUST 380 be 1. Update Response and Update Acknowledge also have a Sequence 381 Number and a Flush Flag. 383 4.1 Update Request 385 The Update Request has the Command/Operation value 9. 387 It is a request to the peer system to send ALL appropriate elements 388 in its routing database. It is retransmitted at periodic intervals 389 (every 5 seconds) until an Update Response message is received with 390 the Flush flag set. 392 An Update Request is transmitted in the following circumstances: 394 o Firstly when the router is powered on. 396 o Secondly when the circuit manager indicates a destination has been 397 in an unreachable (circuit down) state and changes to a reachable 398 (circuit up) state. 400 An Update Request may also be sent at other times to compensate for 401 discarding non-optimal routing information or if an Update Response 402 continues to be unacknowledged (see section 6.3). 404 4.2 Update Response 406 The Update Response has the Command/Operation value 10. 408 It is a message containing zero or more routes in an update. It is 409 retransmitted at periodic intervals until an Update Acknowledge is 410 received. 412 An Update Response message MUST be sent: 414 o In response to an Update Request. The Update Response MUST have 415 the Flush flag set. Other Update Responses should NOT be sent 416 until an Update Acknowledge has been received acknowledging the 417 Flush flag. 419 The remainder of the database MUST then be sent as a series of 420 Update Responses the Flush flag NOT set. 422 o An Update Response with the Flush flag set MUST also be sent at 423 power on to flush the peer's routing table learned from a previous 424 incarnation. This Update Response SHOULD NOT contain any routes. 425 This avoids any possibility of an acknowledgement being received 426 to a response sent BEFORE the unit was restarted causing confusion 427 about which routes are being acknowledged. 429 Update Response messages continue to be sent any time there is fresh 430 routing information to be propagated. 432 Each new Update Response is given a different Sequence Number. The 433 Sequence Number only has 'meaning' to the sender of the Update 434 Response. The same Update Response sent to different peers MAY have 435 a different Sequence Number. 437 An Update Response packet with the Flush flag set MUST be sent to a 438 peer: 440 o At power on. 442 o In response to an Update Request packet. 444 o After transitioning from a circuit down to a circuit up state. 446 After sending an Update Flush, the full database MUST be sent 447 subsequently. 449 4.3 Update Acknowledge 451 The Update Acknowledge has the Command/Operation value 11. 453 It is a message sent in response to every Update Response packet 454 received. If the Update Response packet has the flush flag set then 455 so should the Update Acknowledge packet. 457 5. Packet Formats 459 5.1 Update Header 461 To support the mechanism outlined in this proposal the packet format 462 for RIP Version 1 [1], RIP Version 2 [2] and Netware RIP and SAP [3] 463 are modified to include an additional small header when using 464 Commands Update Request (9), Update Response (10) and Update 465 Acknowledge (11). Commands are called Operations in Netware. 467 Update Request (9): 469 0 1 2 3 3 470 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 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Version (1) | must be zero (3) | 473 +-------------------------------+-------------------------------+ 475 Update Response (10) and Update Acknowledge (11): 477 0 1 2 3 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Version (1) | Flush (1) | Sequence Number (2) | 481 +-------------------------------+-------------------------------+ 483 Four octet Update headers, with each tick mark representing one 484 bit. All fields are coded in network byte order (big-endian). 486 Figure 2. Update Headers. 488 Version MUST be 1 in all headers. Any packets received for a 489 different Version MUST be silently discarded. 491 The Sequence Number MUST be incremented every time a new Update 492 Response packet is sent on the WAN. The Sequence Number is unchanged 493 for retransmissions. The Sequence Number wraps round at 65535. 495 Flush is set to 1 in an Update Response if the peer is required to 496 start timing out its entries - otherwise it is set to zero. Any 497 other values MUST be silently discarded. 499 The peer returns an Update Acknowledge containing the same Sequence 500 Number and Flush. 502 5.2 IP Routing Information Protocol Version 1 504 IP RIP [1] is a UDP-based protocol which generally sends and receives 505 datagrams on UDP port number 520. 507 To support the mechanism outlined in this proposal the packet format 508 for RIP Version 1 [1] is modified when using Commands Update Request 509 (9), Update Response (10) and Update Acknowledge (11). See Figure 3. 511 5.3 IP Routing Information Protocol Version 2 513 IP RIP Version 2 [2] is an enhancement to IP RIP Version 1 which 514 allows RIP updates to include subnetting information. 516 To support the mechanism outlined in this proposal the packet format 517 for RIP Version 2 [2] is modified when using Commands Update Request 518 (9), Update Response (10) and Update Acknowledge (11). See Figure 4. 520 5.4 Netware Routing Information Protocol 522 Netware [3] supports a mechanism that allows routers on an 523 internetwork to exchange routing information using the Routing 524 Information Protocol (RIP) which runs over the Internetwork Packet 525 Exchange (IPX) protocol using socket number 453h. 527 To support the mechanism outlined in this proposal the packet format 528 for Novell RIP [3] is modified when using Operations Update Request 529 (9), Update Response (10) and Update Acknowledge (11). See Figure 5. 531 5.5 Netware Service Advertising Protocol 533 Netware [3] also supports a mechanism that allows servers on an 534 internetwork to advertise their services by name and type using the 535 Service Advertising Protocol (SAP) which runs over the Internetwork 536 Packet Exchange (IPX) protocol using socket number 452h. SAP 537 operates on similar principals to running RIP. Routers act as SAP 538 agents, collecting service information from different networks and 539 relay it to interested parties. 541 To support the mechanism outlined in this proposal the packet format 542 for Novell SAP [3] is modified when using Operations Update Request 543 (9), Update Response (10) and Update Acknowledge (11). See Figure 6. 545 0 1 2 3 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Command (1) | RIP Version (1)| must be zero (2) | 549 +---------------+---------------+-------------------------------+ 551 0 1 2 3 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Update Header (4) | 555 +-------------------------------+-------------------------------+ 557 Update Response then has up to 25 routing entries (each 20 octets): 559 0 1 2 3 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Address Family Identifier (2) | must be zero (2) | 563 +-------------------------------+-------------------------------+ 564 | IP address (4) | 565 +---------------------------------------------------------------+ 566 | must be zero (4) | 567 +---------------------------------------------------------------+ 568 | must be zero (4) | 569 +---------------------------------------------------------------+ 570 | Metric (4) | 571 +---------------------------------------------------------------+ 572 . 573 . 575 The format of an IP RIP datagram in octets, with each tick mark 576 representing one bit. All fields are coded in network byte order 577 (big-endian). 579 The four octets of the Update header are included in Update Request 580 (Command 9), Update Response (10) and Update Acknowledge (11) 581 packets. They are not present in packet types in the original RIP 582 Version 1 specification. 584 Figure 3. IP RIP Version 1 packet format 586 0 1 2 3 3 587 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 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Command (1) |RIP Version (1)| must be zero (2) | 590 +---------------+---------------+-------------------------------+ 592 0 1 2 3 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Update Header (4) | 596 +-------------------------------+-------------------------------+ 598 Update Response then has up to 25 routing entries (each 20 octets): 600 0 1 2 3 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Address Family Identifier (2) | Route Tag (2) | 604 +-------------------------------+-------------------------------+ 605 | IP address (4) | 606 +---------------------------------------------------------------+ 607 | Subnet Mask (4) | 608 +---------------------------------------------------------------+ 609 | Next Hop (4) - must be zero | 610 +---------------------------------------------------------------+ 611 | Metric (4) | 612 +---------------------------------------------------------------+ 613 . 614 . 616 The format of an IP RIP Version 2 datagram in octets, with each 617 tick mark representing one bit. All fields are coded in network 618 byte order (big-endian). 620 The four octets of the Update header are included in Update Request 621 (Command 9), Update Response (10) and Update Acknowledge (11) 622 Packets. They are not present in packet types in the original RIP 623 Version 2 specification. 625 Next Hop MUST be zero, since Triggered RIP can NOT advertise routes 626 on behalf of other WAN routers. 628 If authentication is used it immediately follows the Update header. 630 Figure 4. IP RIP Version 2 packet format 632 0 1 1 633 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Operation (2) | 636 +---------------+---------------+ 638 0 1 2 3 3 639 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 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Update Header (4) | 642 +-------------------------------+-------------------------------+ 644 Update Response then has up to 50 routing entries (each 8 octets): 646 0 1 2 3 3 647 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 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Network Number (4) | 650 +---------------------------------------------------------------+ 651 | Number of Hops (2) | Number of Ticks (2) | 652 +---------------------------------------------------------------+ 653 . 654 . 656 The format of a Netware RIP datagram in octets, with each tick mark 657 representing one bit. All fields are coded in network byte order 658 (big-endian). 660 The four octets of the Update header are included in Update Request 661 (Operation 9), Update Response (10) and Update Acknowledge (11) 662 packets. They are not present in packet types in the original 663 Novell RIP specification. 665 Figure 5. Netware RIP packet format 667 0 1 1 668 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | Operation (2) | 671 +---------------+---------------+ 673 0 1 2 3 3 674 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 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | Update Header (4) | 677 +-------------------------------+-------------------------------+ 679 Update Response then has up to 8 service entries (each 64 octets): 681 0 1 2 3 3 682 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 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Service Type (2) | | 685 +-------------------------------+ | 686 | Service Name (48) | 687 | . | 688 . 689 . +-------------------------------+ 690 | . | Network Address (4) | 691 +-------------------------------+-------------------------------+ 692 | Network Address (cont) | | 693 +-------------------------------+ | 694 | Node Address (6) | 695 +-------------------------------+-------------------------------+ 696 | Socket Address (2) | Hops to Server (2) | 697 +-------------------------------+-------------------------------+ 698 . 699 . 701 The format of a Netware SAP datagram in octets, with each tick mark 702 representing one bit. All fields are coded in network byte order 703 (big-endian). 705 The four octets of the Update header are included in Update Request 706 (Operation 9), Update Response (10) and Update Acknowledge (11) 707 packets. They are not present in packet types in the original 708 Novell SAP specification. 710 Figure 6. Netware SAP packet format 712 6. Timers 714 Three timers are supported to handle the triggered update mechanism: 716 o Database timer. 718 o Hold down timer. 720 o Retransmission timer. 722 An optional over-subscription timer MAY also be supported. 724 6.1 Database Timer 726 Routes learned by an Update Response are normally considered to be 727 permanent. 729 When an Update Response with the Flush flag set is received, all 730 routes learned from that next hop router should start timing out as 731 if they had (just) been learned from a conventional Response (Command 732 2). 734 Namely each route exists while the database entry timer (usually 180 735 seconds) is running and is advertised on other interfaces as if still 736 present. The route is then advertised as unreachable while a further 737 hold down timer is allowed to expire. 739 6.2 Hold down Timer 741 A hold down timer of 120 seconds is started on a route: 743 o When the database timer for the route expires. 745 o When a formerly reachable route changes to unreachable in an 746 incoming response. 748 o When a circuit down is received from the circuit manager. 750 While the hold down timer is running routes are advertised as 751 unreachable on other interfaces. 753 When the hold down timer expires the route MAY be deleted from the 754 database PROVIDING its unreachability has been successfully 755 propagated to all WAN destinations, or the remaining WAN destinations 756 are in a circuit down state. If a route can not be deleted when the 757 hold-down timer expires, it MAY subsequently be deleted when each and 758 every peer is either up-to-date or is in a circuit down state. 760 If the hold down timer is already running it is NOT reset by any 761 events which would start the hold down timer. 763 6.3 Retransmission Timer 765 The routing task runs a retransmission timer: 767 o An Update Request packet is retransmitted periodically until an 768 Update Flush packet is received. An Update Flush packet is an 769 Update Response packet with the Flush field set. It need not 770 contain routes. 772 o An Update Response packet is retransmitted periodically until an 773 Update Acknowledge packet is received containing the same Sequence 774 Number. 776 With call set up time on the WAN being of the order of a second, a 777 value of 5 seconds for the retransmission timer is appropriate. 779 To prevent against failures in the circuit manager a limit SHOULD be 780 placed on the number of retransmissions. If no response has been 781 received after a configurable length of time (say 180 seconds) routes 782 via the next hop router are marked as unreachable, the hold down 783 timer is started and the entry is advertised as unreachable on other 784 interfaces. 786 The next hop router may then be polled with Update Requests at a 787 reduced frequency. A suitable poll interval would be of the order of 788 minutes rather than seconds. Alternatively an Update Request could 789 be initiated by administrative action. When a response is received 790 the routers should perform a complete exchange of routing 791 information. 793 6.4 Over-subscription Timer 795 Over-subscription is where there are more next hop routers to send 796 updates to on the WAN than there are channels. For example 3 next 797 hop routers accessed by an ISDN Basic Rate Interface (BRI) which can 798 only support 2 calls simultaneously. 800 To avoid route oscillation routes may NOT be marked unreachable 801 immediately on receiving a circuit down message from the circuit 802 manager. A timeout MAY be used to delay marking the routes 803 unreachable for sufficiently long to allow the calls to 'time 804 division multiplex' over the available channels. A timeout as long 805 as the regular 180 second RIP route timeout MAY be suitable. In 806 general the greater the over-subscription, the longer the time out 807 should be. 809 Implementations wishing to support over-subscription may implement 810 the delay within the circuit manager or within the routing 811 application. 813 If the delay is implemented within the routing application the 814 routing entries MUST NOT start timing out during the delay. This 815 allows the circuit up message to be ignored if the timeout after 816 receiving the circuit down has still to expire. This avoids any 817 confusion if the peer had previously issued a Route Flush command and 818 was part way through an update. 820 7. Security Considerations 822 The circuit manager is required to be provided with a list of 823 physical addresses to enable it to establish a call to the next hop 824 router. The circuit manager SHOULD only allow incoming calls to be 825 accepted from the same well defined list of routers. 827 Elsewhere in the system there will be a set of logical address and 828 physical address tuples to enable the network protocols to run over 829 the correct circuit. This may be a lookup table, or in some 830 instances there may be an algorithmic conversion between the two 831 addresses. 833 The routing (or service advertising) task MUST be provided with a 834 list of logical addresses to which triggered updates are to be sent 835 on the WAN. The list MAY be a subset of the list of next hop routers 836 maintained by the circuit manager. 838 RIP Version 2 also allows further authentication of Triggered RIP 839 packets. 841 Appendix A - Implementation Suggestion 843 This section suggests how the database might be structured to handle 844 Triggered RIP. 846 Each entry in the database is given a unique route number. Every 847 time a best route to a network changes, a global route number is 848 incremented and the changed route is given the new route number. 849 Note that this route number is completely internal to the router and 850 has no bearing on the Sequence Number sent in Update Responses sent 851 to the peer. 853 The route number size should be large enough so as not to wrap round 854 - or the routes can be renumbered before it becomes a problem. Re- 855 numbering requires that the database environment is stable (No Update 856 Responses are queued awaiting Acknowledgement) 857 Is is probably easier to manage the routes if they are also chained 858 together using a pointer to a later (and possibly also a pointer to 859 an earlier) entry which reflect the route number/age. 861 Performing a complete update then consists of running though the 862 routes from the oldest to the latest and sending them out in Update 863 Responses. Subsequent changes to the database are treated as sending 864 out only the changed entries (from the previous latest to the new 865 latest). 867 When allowing for several packets in flight care must be taken with 868 retransmissions. An Update Response 'retransmission' MAY be 869 different from the original. When transmitting a sequence of Update 870 Responses each Response packet contains a number of routes which is a 871 'time-slice' of the database. Initially the time-slice might be 872 represented by a series of routes with consecutive route numbers. 873 Consider sending three Update Responses with Sequence numbers 10,11 874 and 12 each containing 10 routes: 876 Sequence Number Routes represented by Route Numbers 878 10 101, 102, 103, 104, 105, 106, 107, 108, 109, 110 880 11 111, 112, 113, 114, 115, 116, 117, 118, 119, 120 882 12 121, 122, 123, 124, 125, 126, 127, 128, 129, 130 884 If these Update Responses are NOT acknowledged, but in the meantime 885 the routing database has changed and the routes represented by route 886 numbers 104, 112 - 116 and 127 have changed and been assigned new 887 route numbers 131 - 137, the retransmission will look like: 889 Sequence Number Routes represented by Route Numbers 891 10 101, 102, 103, 105, 106, 107, 108, 109, 110 893 11 111, 117, 118, 119, 120 895 12 121, 122, 123, 124, 125, 126, 128, 129, 130 897 13 131, 132, 133, 134, 135, 136, 137 899 To perform a retransmission it is VERY IMPORTANT that the 900 retransmission contains only the SUB-SET of route numbers which 901 currently apply. If there are NO suitable routes to send, it is not 902 necessary to send an empty retransmission. 904 An alternative 'retransmission' strategy is to always use different 905 sequence numbers when resending updates. Consider transmitting 906 packets with sequence numbers 10 through 20 - and responses are 907 received from all packets except those with sequence numbers 14 and 908 17. In this case only the data in packets 10 through 13 can be 909 considered to be acknowledged. The data from packet 14 onwards MUST 910 be re-sent and given new sequence numbers starting at 21. 912 References 914 [1] Hedrick. C., "Routing Information Protocol", RFC 1058, Rutgers 915 University, June 1988. 917 [2] Malkin. G., "RIP Version 2 - Carrying Additional Information", 918 RFC 1723, Xylogics, November 1994. 920 [3] Novell Incorporated., "IPX Router Specification", Version 1.20, 921 October 1993. 923 [4] Meyer. G., "Extensions to RIP to Support Demand Circuits", 924 Spider Systems, February 1994. 926 Authors' Address: 928 Gerry Meyer 929 Shiva 930 Stanwell Street 931 Edinburgh EH6 5NG 932 Scotland, UK 934 Phone: (UK) 131 554 9424 935 Fax: (UK) 131 467 7749 936 Email: gerry@europe.shiva.com 938 Steve Sherry 939 Xyplex 940 295 Foster St. 941 Littleton, MA 01460 943 Phone: (US) 508 952 4745 944 Fax: (US) 508 952 4887 945 Email: shs@xyplex.com