diff options
Diffstat (limited to 'doc/rfc/rfc2091.txt')
| -rw-r--r-- | doc/rfc/rfc2091.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc2091.txt b/doc/rfc/rfc2091.txt new file mode 100644 index 0000000..76a164d --- /dev/null +++ b/doc/rfc/rfc2091.txt @@ -0,0 +1,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] + |