As per Relevance of the word triggered, we have this rfc below:
Network Working Group G.
Request for Comments: 1582 Spider
Category: Standards Track February 1994
Extensions to RIP to Support Demand
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Running routing protocols on connection oriented Public
Networks, for example X.25 packet switched networks or ISDN, can
expensive if the standard form of periodic broadcasting of
information is adhered to. The high cost arises because a
has to all practical intents and purposes be kept open to
destination to which routing information is to be sent, whether
not it is being used to carry user data
Routing information may also fail to be propagated if the number
destinations to which the routing information is to be sent
the number of channels available to the router on the Wide
Network (WAN).
This memo defines a generalized modification which can be applied
Bellman-Ford (or distance vector) algorithm information
protocols, for example IP RIP, Netware RIP or Netware SAP,
overcomes the limitations of the traditional methods described above
The routing protocols support a purely triggered update mechanism
demand circuits on WANs. The protocols run UNMODIFIED on LANs
fixed point-to-point links
Routing information is sent on the WAN when the routing database
modified by new routing information received from another interface
When this happens a (triggered) update is sent to a list
destinations on other WAN interfaces. Because routing protocols
datagram based they are not guaranteed to be received by the
router on the WAN. An acknowledgement and retransmission
is provided to ensure that routing updates are received
Meyer [Page 1]
RFC 1582 Demand RIP February 1994
The WAN circuit manager advises the routing applications on
reachability and non-reachability of destinations on the WAN
I would like to thank colleagues at Spider, in particular
Edmonstone, Tom Daniel and Alam Turland, Yakov Rekhter (IBM),
Steenstrup (BBN), and members of the RIP-2 working group of the
for stimulating discussions and comments which helped to clarify
memo
The following language conventions are used in the items
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
where not required for interoperability
o SHOULD -- the item should be followed for all but exceptional cir
cumstances
o MAY or optional -- the item is truly optional and may be
or ignored according to the needs of the implementor
The words "should" and "may" are also used, in lower case, in
more ordinary senses
Table of
1. Introduction ........................................... 3
2. Running a routing Protocol on the WAN .................. 4
2.1. Overview ......................................... 4
2.2. Presumption of Reachability ...................... 6
2.3. WAN Router list .................................. 7
2.4. Triggered Updates and Unreliable Delivery ........ 8
2.5. Guaranteeing delivery of Routing Updates ......... 8
2.6. The Routing Database ............................. 9
2.7. New Packet Types ................................. 10
2.8. Fragmentation .................................... 12
2.9. Preventing Queue Overload ........................ 13
3. IP Routing Information Protocol Version 1 .............. 13
4. IP Routing Information Protocol Version 2 .............. 16
5. Netware Routing Information Protocol ................... 17
6. Netware Service Advertising Protocol ................... 20
7. Timers ................................................. 24
Meyer [Page 2]
RFC 1582 Demand RIP February 1994
7.1. Database Timer ................................... 24
7.2. Retransmission Timer ............................. 25
7.3. Reassembly Timer ................................. 26
8. Implementation Considerations ...........................27
9. Security Considerations ................................ 27
10. References ............................................. 28
11. Author's Address ....................................... 29
1.
Routers are used on connection oriented networks, such as X.25
switched networks and ISDN networks, to allow potential
to a large number of remote destinations. Circuits on the Wide
Network (WAN) are established on demand and are relinquished when
traffic subsides. Depending on the application, the
between any two sites for user data might actually be short
relatively infrequent
Practical experience of routing shows that periodic 'broadcasting'
routing updates on the WAN is unsatisfactory on several counts
o Running a routing protocol like RIP is expensive if the
form of transmitting routing information to every next hop
every 30 seconds is adhered to. The more routers there
wishing to exchange information the worse the problem. If
are N routers on the WAN, N * (N - 1) routing updates are sent
N * (N - 1)/2 connections every broadcast period
The expense arises because a circuit has to be kept open to
destination to which routing information is to be sent.
updates are sufficiently frequent that little benefit is
on most networks by attempting to set up a call purely
the duration of the routing update. (There are often minimum
charges, or there is a charge to set up a call irrespective
what data is sent.)
The option of reducing the 'broadcast' frequency, while
the cost, would make the system less responsive
o The number of networks to be connected (N) on the WAN can
exceed the number of simultaneous calls (M) which the
can support. If this happens the routing 'broadcast' will
reach M next hop routers, and (N - M) next hop routers will
receive the routing update
A basic rate ISDN interface can support 2 simultaneous calls,
even the number of logical channels most users subscribe to on
X.25 network is not large. There is no fundamental reason
Meyer [Page 3]
RFC 1582 Demand RIP February 1994
routing protocols should restrict the user to routing between
few sites
o Since there is no broadcast facility on the WAN, 'broadcasting'
routing information actually consists of sending the
separately to all known locations. This means that N
updates are queued for transmission on the WAN link (in
to any data which might be queued).
Routers take a pragmatic view on queuing datagrams for the WAN
If the queue length gets too long, so that datagrams at the end
the queue would take too long be transmitted in a reasonable
(say 1 to 2 seconds) the router may start discarding them. On
X.25 network, with slow line speeds (perhaps 9600 baud), it
not take too many routing updates to fulfill this condition if
link is also actively being used to carry user data
This memo addresses all the above problems
The approach taken is to modify the routing protocols so as to
information on the WAN only when there has been an update to
routing database OR a change in the reachability of a next hop
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
reliability
This memo describes the modifications required for Bellman-Ford (
distance vector) algorithm information broadcasting protocols,
as IP RIP [1,2] or Netware RIP and SAP [3] on the WAN. The
run unmodified on Local Area Networks (LANs) or fixed point-to-
links, and so interoperate transparently with
adhering to the original specifications
2. Running Routing Protocols on the
2.1
Multiprotocol routers are used on connection oriented Wide
Networks (WANs), such as X.25 packet switched networks and
networks, to interconnect LANs. By using the multiplexing
of the underlying WAN technology, several LANs can be
simultaneously through a single physical interface on the router
A circuit manager provides an interface between the
network layers (IP, IPX, CLNP etc) and the connection oriented
(X.25 or ISDN). Figure 1 shows a schematic representative
Meyer [Page 4]
RFC 1582 Demand RIP February 1994
showing the relationship between routing protocols, the
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
protocols, on its upper interface. On its lower interface,
may support one or more subnetworks. A subnetwork may support
number of Virtual Circuits
Figure 1. Representative Multiprotocol Router
The router has a translation table which relates the network
address of the next hop router to the physical address used
establish a Virtual Circuit (VC) to it. Datagrams may
encapsulated in a header to distinguish the network layer
[5].
The circuit manager takes datagrams from the connectionless
layer protocols and (if one is not currently available) opens a VC
the next hop router. A VC can carry all traffic between two end
point routers for a given network layer protocol (or with
encapsulation all network layer protocols). An idle timer is used
close the VC when the datagrams stop arriving at the circuit manager
Running routing protocols on the WAN has traditionally consisted
making small modifications to the methods used on LANs.
Meyer [Page 5]
RFC 1582 Demand RIP February 1994
routing information would be broadcast periodically on a
interface, it is converted to a series of periodic updates sent to
list of addresses on the WAN
This memo targets two areas
o Eliminating the overkill inherent in periodic transmission
routing updates
o Overcoming the bandwidth limitations on the WAN: the number
simultaneous VCs to next hop routers and restricted
throughput which the WAN link can support
The first of these is overcome by transmitting routing
(called routing responses) only when required
o Firstly, when a specific request for a routing update has
received
o Secondly, when the routing database is modified by
information from another interface
Update information received in this way is not
propagated on other interfaces immediately, but is delayed for
few seconds to allow information from several updates to
grouped
o Thirdly, when the circuit manager indicates that a
has changed from an unreachable (circuit down) to a
(circuit up) state
Because of the inherent unreliability of a datagram based system
both routing requests and routing responses require acknowledgement
and retransmission in the event of NOT receiving an acknowledgement
To overcome the bandwidth limitations the routing application
perform a form of self-imposed flow control, to spread
updates out over a period of time
2.2 Presumption of
If a routing update is received from a next hop router on the WAN
entries in the update are thereafter always considered to
reachable, unless proven otherwise
o If in the normal course of routing datagrams, the circuit
fails to establish a connection to the next hop router,
notifies the routing application that the next hop router is
Meyer [Page 6]
RFC 1582 Demand RIP February 1994
reachable through an internal circuit down message
The routing application then goes through a process of timing
database entries to make them unreachable in the routing sense
o If the circuit manager is subsequently able to establish
connec tion to the next hop router, it will notify the
applica tion that the next hop router is reachable through
internal circuit up message
The routing application will then exchange messages with the
hop router so as to re-prime their respective routing
with up-to-date information
Handling of circuit up and circuit down messages requires that
circuit manager takes responsibility for establishing (
reestablishing) the connection in the event of a next hop
becoming unreachable. A description of the processes the
manager adopts to perform this task is outside the scope of
memo
2.3 WAN Router
The routing task MAY be provided with a list of routers to
routing updates to on the WAN. It will comprise of the
addresses of next hop routers for which the router has a logical
physical address mapping. Entries in the list SHOULD be
(on a per-peer basis) as follows
o Running the standard routing protocol, namely
updates periodically with the packet formats used in
broadcasts
This option is supported to allow interoperability with
routing implementations, and might also be appropriate if
of the destinations are using Permanent Virtual Circuits (PVCs
rather than SVCs
o Running the triggered update routing protocol proposed in
memo
Omitting an address from both of these categories is equivalent
not running the routing protocols
If routing packets arrive from a destination not supporting
appropriate variant they MUST be discarded
Meyer [Page 7]
RFC 1582 Demand RIP February 1994
2.4 Triggered Updates and Unreliable
If triggered update information is sent to next hop routers on
WAN only once it can fail to arrive for one of the following reasons
o A free VC resource might not be available, because of
restricted number of X.25 logical channels or ISDN B-channels
o The transmit queue might be full - requiring the datagram to
discarded
o The VC might be pre-empted (in favour of establishing a VC
another next hop router) while the datagram is in a queue
resulting in the queue being flushed and the
discarded
o In cases where the method of transport is not guaranteed,
example with PPP where there is no acknowledgement
retransmission of HDLC frames, a corrupted frame will result
the loss of the datagram
2.5 Guaranteeing delivery of Routing
To guarantee delivery of routing updates on the WAN
acknowledgement and retransmission scheme MUST be used
o Send a routing update to a next hop router on the WAN
o The other router responds with an acknowledgement packet
The original router receives the acknowledgement
o Otherwise the original router retransmits the update until
acknowledgement is received
Retransmission timer values are covered in section 7.
In cases where the routing database is modified before
acknowledgement is received a new routing update with
updated sequence number is sent out. If an acknowledgement
the old routing update is received it is ignored
o A router only updates its routing database when it receives
complete update, which may consist of several fragments.
fragment is individually acknowledged
The above mechanism caters for cases where the datagram is
because of a frame error or is discarded because of an over-
Meyer [Page 8]
RFC 1582 Demand RIP February 1994
queue. The routing update and acknowledgement will eventually
get through
In cases where the circuit manager cannot establish a connection,
mechanism is provided to allow the circuit manager to inform
routing task of the failure to make a connection so that it
suppress retransmissions until a circuit becomes available
2.6 The Routing
A requirement of using triggered updates for propagating
information is that NO routing information ever gets LOST
DISCARDED
The routing database MUST adopt one of the following strategies
o It must keep ALL alternative routing information it learns
any routing updates from the LAN and the WAN, so that if
best route disappears an alternative route (if available)
replace it as the new best route
o If the amount of memory this consumes is problematic the
application must keep SOME alternative routing information -
a best route and two alternatives
If the router ever has to discard routing information about
route it should note the fact. If the routes that have
kept disappear because they have become unreachable, the
MUST issue a request on all interfaces to try and
discarded alternatives
It is recommended that the request is issued BEFORE all
to a destination have been lost
Entries in the routing database can either be permanent or temporary
Entries learned from broadcasts on LANs are temporary. They
expire if not periodically refreshed by further broadcasts
Entries learned from a triggered response on the WAN are 'permanent'.
They MUST not time out in the normal course of events. The
state MUST be changed to 'temporary' by the following events
o The arrival of a routing update containing the entry set
unreachable
The normal hold down timer MUST be started, after which
entry disappears from the routing database
Meyer [Page 9]
RFC 1582 Demand RIP February 1994
o The arrival of a routing update with the entry absent
If the hold down timer is not already running, the entry MUST
set to unreachable and the hold down timer started
o A message sent from the circuit manager, to indicate that
failed to make a connection in normal running
The routing table MUST be scanned for all routes via that
hop router. Aging of these routing entries MUST commence.
the aging timer expires the entry MUST be set to unreachable
the hold down timer started. If the hold down timer expires
entry disappears from the routing database
o If the interface goes down, the circuit manager should
that all circuits on that interface have gone down
Database timer values are covered in section 7.
2.7 New Packet
To support triggered updates, three new packet types MUST
supported
TRIGGERED
A request to the responding system to send
appropriate elements in its routing database
A triggered request is retransmitted at
intervals until a triggered response is received
Routing requests are transmitted in the
circumstances
o Firstly when the router is powered on
o Secondly when the circuit manager indicates
destination has been in an unreachable (circuit down
state for an extended period and changes to
reachable (circuit up) state
o Thirdly in the event of all routing update
failing to arrive within a set period
o It may also send triggered requests at other times
compensate for discarding non-optimal
information
Meyer [Page 10]
RFC 1582 Demand RIP February 1994
TRIGGERED
A message containing all appropriate elements of
routing database. An appropriate element is an
NOT learned from the interface to which the
information is being sent out. This is known as "
horizon".
Stability is improved by adding "poisoned reverse"
routes learned from a destination. This consists of
including some routes learned from a destination
routing updates sent back to that destination,
setting the routes as unreachable. A route is
poisoned if it is the best route (rather than an
alternative route) in the database
A triggered response message may be sent in response to
triggered request, or it may be an update message
because of a change in the routing database
A triggered response message MUST be sent in response
a triggered request message even if there are no
to propagate. This would be the case for a host
had a WAN interface only, but which wished to run
triggered update protocol
A triggered response is retransmitted at
intervals until a triggered acknowledgement is received
TRIGGERED
A message sent in response to every triggered
packet received
Triggered response and triggered acknowledgement packets MUST
additional fields for a sequence number, fragment number and
of fragments
If a triggered request or response is not acknowledged after 10
retransmissions, routes to the destination should be marked
unreachable for the duration of a hold down timer before
deleted
The destination should then be polled at a lower frequency
triggered request packets. When a triggered response is received
the router should prime the next hop router my sending its
database through triggered response packets
Meyer [Page 11]
RFC 1582 Demand RIP February 1994
Strictly speaking polling should occur indefinitely to
database integrity. However the administrator MAY wish the router
cease polling after a few attempts believing that the lack
response is due to a mis-configuration of the next hop router.
destination should be marked as NOT supporting the mechanism and
further routing messages should be sent to that destination
Before marking the destination as not supporting the mechanism,
least 5 triggered request polls (without acknowledgement) should
sent
If a destination marked as not supporting the mechanism,
sends a valid 'triggered' message, the destination should be
as supporting the mechanism once more (to allow for the next
router's configuration being changed). It should be sent a
request and a triggered response to obtain and propagate up-to-
routing information
2.8
If a routing update is sufficiently large, the information MUST
fragmented over several triggered response packets
o Each fragment MUST be individually acknowledged with a
acknowledgement packet
The sender of the routing update MUST periodically
fragments which have not been acknowledged (or until
destination is marked as not supporting the mechanism).
o A router receiving fragments MUST re-assemble them
updating its routing database
o If all fragments are not received within four times
retransmit period, they MUST be discarded
A triggered request packet MUST then be sent to the
of the routing update
On receiving the triggered request packet, the originator of
routing update MUST retransmit ALL fragments
o If a fragment with an updated sequence number is received,
fragments with the earlier sequence number MUST be discarded
An updated sequence number is defined as any sequence
that is different. There is no concept of the value of
sequence number conveying its age
Meyer [Page 12]
RFC 1582 Demand RIP February 1994
Fragmentation timer values are covered in section 7.
2.9 Preventing Queue
In order to prevent too many routing messages being queued at a
interface, the routing task MAY operate a scheme
'broadcasting' of a triggered request or triggered response to a
interface is staggered. All routing requests or routing
are not sent to ALL next hop routers on the interface in a
batch
o The routing task should limit the number of outstanding
request messages for which a triggered response has not
received
o The routing task should limit the number of outstanding
response messages for which a triggered acknowledgement has
been received
As outstanding messages are appropriately acknowledged,
messages can be sent out to other next hop routers, until all
hop routers have been sent the message and have acknowledged it
The maximum number of outstanding messages transmitted
acknowledgement is a function of the link speed and the number
other routing protocols operating the triggered update mechanism
Messages should always be acknowledged immediately (even if it
the limit to be exceeded), since a connection is almost
available. This has the potential benefit of allowing the VC
close sooner (on its idle timer).
Sending all triggered request fragments to a destination at once
also beneficial
3. IP Routing Information Protocol Version 1
This section should be read in conjunction with reference [1].
IP RIP is a UDP-based protocol which generally sends and
datagrams on UDP port number 520.
To support the mechanism outlined in this proposal the packet
for RIP version 1 [1] is modified as shown in Figure 2.
Every Routing Information Protocol datagram contains the following
Meyer [Page 13]
RFC 1582 Demand RIP February 1994
COMMAND Commands supported in RIP Version 1 are: request (1),
response (2), traceon (3), traceoff (4), SUN reserved (5).
The fields sequence number, fragment number and number
fragments MUST NOT be included in packets with
command values
The following new commands (with values in brackets)
required
TRIGGERED REQUEST (6)
A request for the responding system to send all of
routing database
Only the first 4 octets of the packet format shown
figure 2 are sent, since all routing information
implied by this request type
TRIGGERED RESPONSE (7)
A message containing all of the sender's
database, excluding those entries learned from
interface to which the routing information is
sent
This message may be sent in response to a
request, or it may be an update message
from a change in the routing database
A triggered response message MUST be sent in
to a triggered request message even if there are
routes to propagate. This would be the case for
host which had a WAN interface only, but which
to run the triggered update protocol
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| command (1) | version (1) | must be zero (2) |
+---------------+---------------+-------------------------------+
The following new fields are inserted for some
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sequence number (2) | fragment (1) |no of frags (1)|
+-------------------------------+-------------------------------+
Meyer [Page 14]
RFC 1582 Demand RIP February 1994
Followed by up to 25 routing entries (each 20 octets
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| address family identifier (2) | must be zero (2) |
+-------------------------------+-------------------------------+
| IP address (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| metric (4) |
+---------------------------------------------------------------+
.
.
The format of an IP RIP datagram in octets, with each tick
representing one bit. All fields are in network order
The four octets: sequence number (2), fragment number (1)
number of fragments (1) are not present in the original
specification. They are only present if command takes
values 7 or 8.
Figure 2. IP Routing Information Protocol packet
TRIGGERED ACKNOWLEDGEMENT (8)
A message sent in response to every triggered
packet received
Only the first 8 octets of the packet format shown
figure 2 are sent
VERSION In this instance Version 1.
SEQUENCE
This is a new field inserted if command takes the values 7
or 8.
The sequence number MUST be incremented every time
information is sent out on a WAN. The sequence
wraps round at 65535.
Meyer [Page 15]
RFC 1582 Demand RIP February 1994
When a triggered acknowledgement is sent the
number is set to the same value as the triggered
packet being acknowledged
The sequence number MUST be identical over fragments. If
fragment is retransmitted the sequence number MUST
change
FRAGMENT
The fragment number is one for the first fragment of
routing update, and is incremented for each
fragment. A fragment can contain up to 25 routing entries
When a triggered acknowledgement is sent the
number is set to the same value as the triggered
packet being acknowledged
NUMBER OF
In a triggered response packet this indicates the number
packets required to complete the routing update
This field has no relevance for triggered
packets so should be set to zero
For triggered response packets the rest of the datagram contains
list of destinations, with information about each. Each entry
this list contains the address family identifier (2 for IP),
destination network or host, and the metric for it. The
format is intended to allow RIP to carry routing information
several different protocols, identifiable by the family identifier
The IP address is the usual Internet address, stored as 4 octets
network order. The metric field contains a value between 1 and 15
inclusive, specifying the current metric for the destination, or
value 16 (representing 'infinity'), which indicates that
destination is not reachable. Each route sent by a router
any previous route to the same destination from the same router
The maximum datagram size is 508 octets, excluding UDP and
headers
4. IP Routing Information Protocol Version 2
An enhancement to IP RIP to include subnetting has recently
available [2]. This section only describes differences from
RFC
Meyer [Page 16]
RFC 1582 Demand RIP February 1994
The triggered update mechanism can be supported by including
triggered request (6), triggered response (7) and
acknowledgement (8) commands described in the previous section
The sequence number, fragment number and number of fragments
are included in triggered response and triggered
commands
The triggered request packet should also contain the 4 extra
corresponding to the sequence number, fragment number and number
fragments fields - but set to zero
Because additional security information is included in RIP Version 2
packets, this MUST be appended to the triggered request and
acknowledgement packets, as well as being present in the
response packet
The version number becomes 2. Other aspects of packet layout
reference [2].
5. Netware Routing Information
This section should be read in conjunction with references [3],
it only describes differences from the specification
Netware [3] is the trade name of Novell Research's protocols
computer communication which are derived and extended from
Network System's (XNS) protocols [4].
Netware supports a mechanism that allows routers on an
to exchange routing information using the Routing
Protocol (RIP) which runs over the Internetwork Packet Exchange (IPX
protocol using socket number 453h
Netware RIP and IP RIP share a common heritage, in that they are
based on XNS RIP, but there is some divergence, mostly at the
format level to reflect the differing addressing schemes
The triggered update mechanism can be applied to Netware RIP.
support the mechanism outlined in this proposal the packet format
Netware RIP is modified as shown in Figure 3.
Every datagram contains the following
Meyer [Page 17]
RFC 1582 Demand RIP February 1994
RIP
Operations supported in standard Netware RIP are:
(1) and response (2).
The fields sequence number, fragment number and number
fragments MUST NOT be included in packets with
operation values
The following new operations are required (with
chosen to be the same as for IP RIP commands):
0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| operation (2) |
+---------------+---------------+
The following new fields are inserted for some
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sequence number (2) | fragment (1) |no of frags (1)|
+-------------------------------+-------------------------------+
Followed by up to 50 routing entries (each 8 octets
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| network number (4) |
+---------------------------------------------------------------+
| number of hops (2) | number of ticks (2) |
+---------------------------------------------------------------+
.
.
The format of a Netware RIP datagram in octets, with each
mark representing one bit. All fields are in network order
The four octets: sequence number (2), fragment number (1)
number of fragments (1) are not present in the original
specification. They are only present if operation takes
values 7 or 8.
Figure 3. Netware Routing Information Protocol packet
Meyer [Page 18]
RFC 1582 Demand RIP February 1994
TRIGGERED REQUEST (6)
A request for the responding system to send all of
routing database
Only the first 2 octets of the packet format shown
figure 3 are sent, since all routing information
implied by this request type
TRIGGERED RESPONSE (7)
A message containing all of the sender's
database, excluding those entries learned from
interface to which the routing information is
sent
This message may be sent in response to a
request, or it may be an update message
from a change in the routing database
A triggered response message MUST be sent in
to a triggered request message even if there are
routes to propagate. This would be the case for
host which had a WAN interface only, but which
to run the triggered update protocol
TRIGGERED ACKNOWLEDGEMENT (8)
A message sent in response to every
response packet received
Only the first 6 octets of the packet format shown
figure 3 are sent
SEQUENCE
This is a new field inserted if operation takes
values 7 or 8.
The sequence number MUST be incremented every
updated information is sent out on a WAN. The
number wraps round at 65535.
When a triggered acknowledgement is sent the
number is set to the same value as the triggered
packet being acknowledged
Meyer [Page 19]
RFC 1582 Demand RIP February 1994
The sequence number MUST be identical over fragments.
a fragment is retransmitted the sequence number MUST
change
FRAGMENT
The fragment number is one for the first fragment of
routing update, and is incremented for each
fragment. A fragment can contain up to 50 routing entries
When a triggered acknowledgement is sent the
number is set to the same value as the triggered
packet being acknowledged
NUMBER OF
In a triggered response packet this indicates the
of packets required to complete the routing update
This field has no relevance for triggered
packets so should be set to zero
For triggered response packets the rest of the datagram contains
list of networks, with information about each. Each entry in
list contains a destination network, and the number of hops
number of ticks for each
The maximum datagram size is 406 octets, excluding the IPX header (
further 30 octets).
6. Netware Service Advertising
This section should be read in conjunction with references [3],
it only describes differences from the specification
Netware [3] also supports a mechanism that allows servers on
internetwork to advertise their services by name and type using
Service Advertising Protocol (SAP) which runs over the
Packet Exchange (IPX) protocol using socket number 452h
SAP operates on similar principals to running RIP. Routers act
SAP agents, collecting service information from different
and relay it to interested parties
To support the triggered update mechanism outlined in this
the packet format for Netware SAP is modified as shown in Figure 4.
Every Service Advertising Protocol datagram contains the following
Meyer [Page 20]
RFC 1582 Demand RIP February 1994
SAP
Operations supported in standard Netware SAP are:
service query (1), general service response (2),
service query (3) and nearest service response (4).
The fields sequence number, fragment number and number
fragments MUST NOT be included in packets with
operation values
The following new operations are required
TRIGGERED GENERAL SERVICE QUERY (6)
A request for the responding system to send
identities of all servers of all types
Only the first 2 octets of the packet format shown
figure 4 are sent, since all service types
implied by this request type
0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| operation (2) |
+---------------+---------------+
The following new fields are inserted for some
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sequence number (2) | fragment (1) |no of frags (1)|
+-------------------------------+-------------------------------+
Meyer [Page 21]
RFC 1582 Demand RIP February 1994
Followed by up to 8 service entries (each 66 octets
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Type (4) |
+---------------------------------------------------------------+
| Service Name (48) |
+ +
.
| . |
+---------------------------------------------------------------+
| Network Address (4) |
+---------------------------------------------------------------+
| Node Address (6) |
+ +-------------------------------+
| | Socket Address (2) |
+---------------------------------------------------------------+
| Hops to Server (2) |
+-------------------------------+
.
.
The format of a Netware SAP datagram in octets, with each
mark representing one bit. All fields are in network order
The four octets: sequence number (2), fragment number (1)
number of fragments (1) are not present in the original
specification. They are only present if operation takes
values 7 or 8.
Figure 4. Netware Service Advertising Protocol packet
TRIGGERED GENERAL SERVICE RESPONSE (7)
A message containing all of the sender's
table, excluding those entries learned from
interface to which the service
information is being sent out
This message may be sent in response to a
general service query, or it may be an update
resulting from a change in the service
database
Meyer [Page 22]
RFC 1582 Demand RIP February 1994
A triggered general service response message MUST
sent in response to a triggered general
message even if there are no services to advertise
This would be the case for a router with a
network which had work stations but no servers on it
TRIGGERED GENERAL SERVICE ACKNOWLEDGEMENT (8)
A message sent in response to every triggered
service response packet received
Only the first 6 octets of the packet format shown
figure 4 are sent
SEQUENCE
This is a new field inserted if operation takes the
7 or 8.
The sequence number MUST be incremented every time
information is sent out on a WAN. The sequence
wraps round at 65535.
When a triggered general service acknowledgement is
the sequence number is set to the same value as
triggered general service response packet
acknowledged
The sequence number MUST be identical over fragments.
a fragment is retransmitted the sequence number MUST
change
FRAGMENT
The fragment number is one for the first fragment of
triggered general service response update, and
incremented for each subsequent fragment. A fragment
contain up to 8 service entries
When a triggered general service acknowledgement is sent
the fragment number is set to the same value as
triggered general service response packet
acknowledged
NUMBER OF
In a triggered response packet this indicates the number
packets required to complete the service update
Meyer [Page 23]
RFC 1582 Demand RIP February 1994
This field has no relevance for triggered
packets so should be set to zero
For triggered general service response packets the rest of
datagram contains a list of services, with information about each
Each entry in this list contains the service type, service name,
address (network, node and socket), and the number of hops to
server
The maximum datagram size is 534 octets, excluding the IPX header (
further 30 octets).
7.
A number of timers are supported to handle the triggered
mechanism
o Database timers
o Retransmission timer
o Reassembly timer
In this section appropriate timer values for IP RIP are suggested
For other routing protocols, only the database timer should need
take different values. The database timer values are chosen to
equivalent timer operation for using the protocol on a LAN.
behaviour of a routing entry when a timer is running
indistinguishable from a routing entry learned from a
update
Implementations MAY make timer values configurable - and
different from the values suggested here - but
requires that all timers on a sub-network should be the same in
routers
7.1 Database
Routes learned by a triggered response command (7) are
considered to be permanent - that is they do NOT time out
activated by one of the following events
o If the circuit manager indicates that a next hop router cannot
contacted, all routes learned from that next hop router
start timing out as if they had (just) been learned from
conventional response command (2).
Meyer [Page 24]
RFC 1582 Demand RIP February 1994
Namely each route exists while the database entry timer
running and is advertised on other interfaces as if
present. The route is then advertised as unreachable while
further hold down timer is allowed to expire, at which point
entry is deleted
If the circuit manager indicates that the next hop router can
contacted while the database entry timer is running, the
are reinstated as permanent entries
If the database entry timer has expired and the circuit
indicates that the next hop router is reachable, the
application MUST issue a triggered request. The routes will
reinstated on the basis of any triggered response packet(s
received
o If a triggered response packet is received in which a route
marked unreachable, the hold down timer MUST be started and
entry is advertised as unreachable on other interfaces.
expiry of the hold down timer the entry is deleted
If a triggered response packet is received in which an
route is ABSENT, the hold down timer MUST also be started
the entry is advertised as unreachable on other interfaces.
expiry of the hold down timer the entry is deleted
For IP RIP the hold down timer should always run for 120 seconds,
be consistent with RIP usage on broadcast networks. The
entry timer should by default run for 180 seconds. The network
be made more responsive by reducing the database entry timer value
However, making this timer too short can lead to
instabilities. The duration of the database entry timer allows
period of grace in which contention for network resources can
resolved by the circuit manager
7.2 Retransmission
The routing task runs a retransmission timer
o When a triggered request is sent it will be
periodically while a triggered response packet is not received
o When a triggered response is sent a note of the sequence
and fragment number(s) of the routing update is kept
Fragments will be retransmitted at periodic intervals while
triggered acknowledgement packet is not received for
appropriate fragment
Meyer [Page 25]
RFC 1582 Demand RIP February 1994
With call set up time on the WAN being of the order of a second,
value of 5 seconds for the retransmission timer is appropriate
If no response is received after 10 retransmissions, routes via
next hop router are marked as unreachable, the hold down timer
be started and the entry is advertised as unreachable on
interfaces. On expiry of the hold down timer the entry is deleted
The next hop router is then polled using a triggered request
at 60 second intervals. If a response is received the routers
exchange routing information using triggered response packets
It may not be desirable to poll indefinitely, since a lack
response (when a circuit is up) is most likely caused by
configuration of the next hop router. An administrator
number of polls (5 or greater) should be provided
If the circuit manager indicates that the next hop router
unreachable, the retransmission is suppressed until the
manager indicates that the next hop router is reachable once more
Counting of the number of retransmissions continues from where
left off prior to the circuit down indication
7.3 Reassembly
When a router receives a triggered response update it
acknowledge each fragment. If the routing update is fragmented
more than one packet, the receiving router MUST store the
until ALL fragments are received
On receiving the first fragment a timer should be started. If
fragments of the routing update are not received within that
they are discarded - and a triggered request is sent back to
originator (with retransmissions if necessary). The originator
then resend ALL triggered response fragments
The reassembly timer should be set to four times the value of
retransmission timer. With a suggested retransmission timer value
5 seconds, the suggested reassembly timer value SHOULD be 20 seconds
Implementations MAY allow the reassembly timer and
timer to be configurable (in the 1:4 ratio), but
will be compromised on WANs where all participating routers DO
support the same values for these timers
Fragments MUST also be discarded if a new fragment with a
sequence number is received. A triggered request MUST not be sent
this instance
Meyer [Page 26]
RFC 1582 Demand RIP February 1994
8. Implementation
In the implementation described in this memo, it is assumed
there is a close binding between the circuit manager and the
applications - that they are in some way the same 'program'. This
not necessarily true of all products which are routers
In particular there are UNIX host implementations in which
routing application is distinct from the kernel, where the
manager is likely to be installed. In such systems it is possible
stop (or crash) the routing applications independently of what
happening in the kernel
Other implementations might have the circuit manager on a
card which again may give the circuit manager a life of its own
In implementations where the applications and circuit manager
independent lives, a keep-alive mechanism MUST be provided
the applications and the circuit manager, so that if the
or network layer dies and is subsequently re-started they
resynchronize their state tables
Ideally, when an application dies, the circuit manager should
all existing VCs appropriate to the application and make no
outgoing calls and reject incoming calls until the application
running again
If the circuit manager is using some form of encapsulation,
applications may be sharing the same VC. If this is the case
circuit manager may wish to filter out datagrams for the
network layer if only one of the applications is affected. But
is not an ideal solution
Conversely if the application believes the circuit manager has died
it should mark all routes via the circuit manager as unreachable
advertise them on other interfaces for the duration of the hold
timer before deleting them
9. Security
Security is provided my a number of aspects
o The circuit manager is required to be provided with a list
physical addresses to enable it to establish a call to the
hop router on an X.25 SVC or ISDN B-channel
The circuit manager SHOULD only allow incoming calls to
accepted from the same well defined list of routers
Meyer [Page 27]
RFC 1582 Demand RIP February 1994
Elsewhere in the system there will be a set of logical
and physical address tuples to enable the network protocols
run over the correct circuit. This may be a lookup table, or
some instances there may be an algorithmic conversion
the two addresses
o The routing (or service advertising) task MUST be provided with
list of logical addresses to which triggered updates are to
sent on the WAN. The list MAY be a subset of the list of
hop routers maintained by the circuit manager
There MAY also be a separate list of next hop routers to
traditional broadcasts of routing (or service advertising
updates should be sent. Next hop routers omitted from
list are assumed to be not participating in routing (or
advertising) updates
The list (or lists) doubles as a list of routers from
routing updates are allowed to be received from the WAN.
routing information received from a router not in
appropriate list MUST be discarded
10.
[1] Hedrick. C., "Routing Information Protocol", STD 34, RFC 1058,
Rutgers University, June 1988.
[2] Malkin. G., "RIP Version 2 - Carrying Additional Information",
RFC 1388, Xylogics, January 1993.
[3] Novell Incorporated., "IPX Router Specification", Version 1.10,
October 1992.
[4] Xerox Corporation., "Internet Transport Protocols", Xerox
Integration Standard XSIS 028112, December 1981.
[5] Malis. A., Robinson. D., and R. Ullmann, "
Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356,
Communications, Computervision Systems Integration,
Software Corporation, August 1992.
Meyer [Page 28]
RFC 1582 Demand RIP February 1994
11. Author's
Gerry
Spider
Stanwell
Edinburgh EH6 5
Scotland,
Phone: (UK) 31 554 9424
Fax: (UK) 31 554 0649
EMail: gerry@spider.co.
Meyer [Page 29]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
