📄 rfc1582.txt
字号:
o A router receiving fragments MUST re-assemble them before
updating its routing database.
o If all fragments are not received within four times the
retransmit period, they MUST be discarded.
A triggered request packet MUST then be sent to the originator
of the routing update.
On receiving the triggered request packet, the originator of the
routing update MUST retransmit ALL fragments.
o If a fragment with an updated sequence number is received, ALL
fragments with the earlier sequence number MUST be discarded.
An updated sequence number is defined as any sequence number
that is different. There is no concept of the value of the
sequence number conveying its age.
Meyer [Page 12]
RFC 1582 Demand RIP February 1994
Fragmentation timer values are covered in section 7.
2.9 Preventing Queue Overload
In order to prevent too many routing messages being queued at a WAN
interface, the routing task MAY operate a scheme whereby
'broadcasting' of a triggered request or triggered response to a WAN
interface is staggered. All routing requests or routing responses
are not sent to ALL next hop routers on the interface in a single
batch:
o The routing task should limit the number of outstanding triggered
request messages for which a triggered response has not been
received.
o The routing task should limit the number of outstanding triggered
response messages for which a triggered acknowledgement has not
been received.
As outstanding messages are appropriately acknowledged, further
messages can be sent out to other next hop routers, until all next
hop routers have been sent the message and have acknowledged it.
The maximum number of outstanding messages transmitted without
acknowledgement is a function of the link speed and the number of
other routing protocols operating the triggered update mechanism.
Messages should always be acknowledged immediately (even if it causes
the limit to be exceeded), since a connection is almost certainly
available. This has the potential benefit of allowing the VC to
close sooner (on its idle timer).
Sending all triggered request fragments to a destination at once is
also beneficial.
3. IP Routing Information Protocol Version 1
This section should be read in conjunction with reference [1].
IP RIP is a UDP-based protocol which generally sends and receives
datagrams on UDP port number 520.
To support the mechanism outlined in this proposal the packet format
for RIP version 1 [1] is modified as shown in Figure 2.
Every Routing Information Protocol datagram contains the following:
Meyer [Page 13]
RFC 1582 Demand RIP February 1994
COMMAND Commands supported in RIP Version 1 are: request (1),
response (2), traceon (3), traceoff (4), SUN reserved (5).
The fields sequence number, fragment number and number of
fragments MUST NOT be included in packets with these
command values.
The following new commands (with values in brackets) are
required:
TRIGGERED REQUEST (6)
A request for the responding system to send all of its
routing database.
Only the first 4 octets of the packet format shown in
figure 2 are sent, since all routing information is
implied by this request type.
TRIGGERED RESPONSE (7)
A message containing all of the sender's routing
database, excluding those entries learned from the
interface to which the routing information is being
sent.
This message may be sent in response to a triggered
request, or it may be an update message resulting
from a change in the routing database.
A triggered response message MUST be sent in response
to a triggered request message even if there are no
routes to propagate. This would be the case for a
host which had a WAN interface only, but which wished
to run the triggered update protocol.
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| command (1) | version (1) | must be zero (2) |
+---------------+---------------+-------------------------------+
The following new fields are inserted for some commands
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sequence number (2) | fragment (1) |no of frags (1)|
+-------------------------------+-------------------------------+
Meyer [Page 14]
RFC 1582 Demand RIP February 1994
Followed by up to 25 routing entries (each 20 octets)
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| address family identifier (2) | must be zero (2) |
+-------------------------------+-------------------------------+
| IP address (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| metric (4) |
+---------------------------------------------------------------+
.
.
The format of an IP RIP datagram in octets, with each tick mark
representing one bit. All fields are in network order.
The four octets: sequence number (2), fragment number (1) and
number of fragments (1) are not present in the original RIP
specification. They are only present if command takes the
values 7 or 8.
Figure 2. IP Routing Information Protocol packet format
TRIGGERED ACKNOWLEDGEMENT (8)
A message sent in response to every triggered response
packet received.
Only the first 8 octets of the packet format shown in
figure 2 are sent.
VERSION In this instance Version 1.
SEQUENCE NUMBER
This is a new field inserted if command takes the values 7
or 8.
The sequence number MUST be incremented every time updated
information is sent out on a WAN. The sequence number
wraps round at 65535.
Meyer [Page 15]
RFC 1582 Demand RIP February 1994
When a triggered acknowledgement is sent the sequence
number is set to the same value as the triggered response
packet being acknowledged.
The sequence number MUST be identical over fragments. If a
fragment is retransmitted the sequence number MUST not
change.
FRAGMENT NUMBER
The fragment number is one for the first fragment of a
routing update, and is incremented for each subsequent
fragment. A fragment can contain up to 25 routing entries.
When a triggered acknowledgement is sent the fragment
number is set to the same value as the triggered response
packet being acknowledged.
NUMBER OF FRAGMENTS
In a triggered response packet this indicates the number of
packets required to complete the routing update.
This field has no relevance for triggered acknowledgement
packets so should be set to zero.
For triggered response packets the rest of the datagram contains a
list of destinations, with information about each. Each entry in
this list contains the address family identifier (2 for IP), a
destination network or host, and the metric for it. The packet
format is intended to allow RIP to carry routing information for
several different protocols, identifiable by the family identifier.
The IP address is the usual Internet address, stored as 4 octets in
network order. The metric field contains a value between 1 and 15
inclusive, specifying the current metric for the destination, or the
value 16 (representing 'infinity'), which indicates that the
destination is not reachable. Each route sent by a router supersedes
any previous route to the same destination from the same router.
The maximum datagram size is 508 octets, excluding UDP and IP
headers.
4. IP Routing Information Protocol Version 2
An enhancement to IP RIP to include subnetting has recently become
available [2]. This section only describes differences from that
RFC.
Meyer [Page 16]
RFC 1582 Demand RIP February 1994
The triggered update mechanism can be supported by including the
triggered request (6), triggered response (7) and triggered
acknowledgement (8) commands described in the previous section.
The sequence number, fragment number and number of fragments fields
are included in triggered response and triggered acknowledgement
commands.
The triggered request packet should also contain the 4 extra octets
corresponding to the sequence number, fragment number and number of
fragments fields - but set to zero.
Because additional security information is included in RIP Version 2
packets, this MUST be appended to the triggered request and triggered
acknowledgement packets, as well as being present in the triggered
response packet.
The version number becomes 2. Other aspects of packet layout follow
reference [2].
5. Netware Routing Information Protocol
This section should be read in conjunction with references [3], since
it only describes differences from the specification.
Netware [3] is the trade name of Novell Research's protocols for
computer communication which are derived and extended from Xerox
Network System's (XNS) protocols [4].
Netware supports a mechanism that allows routers on an internetwork
to exchange routing information using the Routing Information
Protocol (RIP) which runs over the Internetwork Packet Exchange (IPX)
protocol using socket number 453h.
Netware RIP and IP RIP share a common heritage, in that they are both
based on XNS RIP, but there is some divergence, mostly at the packet
format level to reflect the differing addressing schemes.
The triggered update mechanism can be applied to Netware RIP. To
support the mechanism outlined in this proposal the packet format for
Netware RIP is modified as shown in Figure 3.
Every datagram contains the following:
Meyer [Page 17]
RFC 1582 Demand RIP February 1994
RIP OPERATION
Operations supported in standard Netware RIP are: request
(1) and response (2).
The fields sequence number, fragment number and number of
fragments MUST NOT be included in packets with these
operation values.
The following new operations are required (with values
chosen to be the same as for IP RIP commands):
0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| operation (2) |
+---------------+---------------+
The following new fields are inserted for some operations
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -